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Abstract. 


The  Early  Development  of  Programming  Languages 


by  Donald  E.  Knuth  and  Luis  Trabb  Pardo 

Computer  Science  Department 
Stanford  Uhiversity 
Stanford,  California  9^305 


"^This  paper  surveys  the  evolution  of  ^igh  level"  programming  languages 

during  the  first  decade  of  computer  programming  activity.  We  discuss  the 

contributions  of  Zuse  ( *Plankalkul*)  191+5),  Goldstine/von  Neumann  ("i^low 

Diagrams’*^  1946),  Curry  ("‘Composition’^  1948),  Mauchly  et  al.  ("Short  Code^ 

1950),  Burks  (-"intermediate  PL1*)  1950),  Rutishauser  (195l)>  Bohm  (l951)> 

Glennie  ("^AUTOCODE^  1952),  Hopper  et  al.  k-2^ , 1953  )>  Laning/Zierler 

(1953)>  Backus  et  al.  (‘’’'FORTRAN"^  1954-1957),  Brooker  ("'’Mark  I Autocode", 

# r*  JP 

1954),  Kamynin/Liubimskii  ("TTrT-2",  1954),  Ershov  (rtTTTT",  1955 ),  Grems/Porter 
("BACAIC'f,  1955),  Elsworth  et  al.  ("Rompiler  2"^  1955),  Blum  ("ADES",  1956), 
Perils  et  al.  ("IT",  1956),  Katz  et  al.  ('rMATH-MATIC",  1956-1958), 

Hopper  et  al.  ("FLOW-MATIC",  1956-1958),  Bauer/Samelson  (1956-1958). 

The  principal  features  of  each  contribution  are  illustrated;  and  for 
purposes  of  comparison,  a particular  fixed  algorithm  has  been  encoded 
(as  far  as  possible)  in  each  of  the  languages.  This  research  is  based 
primarily  on  unpublished  source  materials,  and  the  authors  hope  that  they 
have  been  able  to  compile  a fairly  complete  picture  of  the  early 
developments  in  this  area. 

This  article  was  commissioned  by  the  Encyclopedia  of  Computer  Science 
and  Technology,  ed.  by  Jack  Belzer,  Albert  G.  Holzman,  and  Allen  Kent, 
and  it  is  scheduled  to  appear  in  vol.  6 or  vol.  7 of  that  encyclopedia 
during  1977* 


The  preparation  of  this  paper  has  been  supported  in  part  by  National 
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The  Early  Development  of  Programming  Languages 

It  is  interesting  and  instructive  to  study  the  history  of  a subject 
not  only  because  it  helps  us  to  understand  how  the  important  ideas  were 
born  — and  to  see  how  the  "human  element"  entered  into  each  development  — 
but  also  because  it  helps  us  to  appreciate  the  amount  of  progress  that 
has  been  made.  This  is  especially  striking  in  the  case  of  programming 
languages,  a subject  which  has  long  been  undervalued  by  computer  scientists. 
After  learning  a high-level  language,  a person  often  tends  to  think  mostly 
of  improvements  he  or  she  would  like  to  see  (since  all  languages  can  be 
improved),  and  it  is  very  easy  to  underestimate  the  difficulty  of  creating 
that  language  in  the  first  place.  The  real  depth  of  this  subject  can 
only  be  properly  perceived  when  we  realize  how  long  it  took  to  develop 
the  important  concepts  which  we  now  regard  as  self  evident.  These  ideas 
were  by  no  means  obvious  a priori,  and  many  years  of  work  by  brilliant 
and  dedicated  people  were  necessary  before  our  current  state  of  knowledge 
was  reached. 

The  goal  of  this  paper  is  to  give  an  adequate  account  of  the  early 
nistory  of  "high  level"  programming  languages,  covering  roughly  the  first 
decade  of  their  development.  Our  story  will  take  us  up  to  1957>  when  the 
practical  importance  of  algebraic  compilers  was  first  being  demonstrated, 
and  when  computers  were  just  beginning  to  be  available  in  large  numbers. 

We  will  see  how  people's  fundamental  conceptions  of  algorithms  and  of  the 
programming  process  evolved  during  the  years  — not  always  in  a forward 
direction  --  culminating  in  languages  such  as  FORTRAN  I.  The  best  languages 
we  shall  encounter  are,  of  course,  very  primitive  by  today' s standards,  but 
they  were  good  enough  to  touch  off  an  explosive  growth  in  language 
development;  the  ensuing  decade  of  intense  activity  has  been  detailed  in 
Jean  Sammet’s  785 -page  book  [SA  69]*  We  shall  be  concerned  with  the  more 
relaxed  atmosphere  of  the  "pre-Babel"  days,  when  people  who  worked  with 
computers  foresaw  the  need  for  important  aids  to  programming  that  did  not 
yet  exist.  In  many  cases  these  developments  were  so  far  ahead  of  their 
time  that  they  remained  unpublished,  and  they  are  still  largely  unknown 
today. 
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Altogether  we  shall  be  considering  about  20  different  languages,  and 


it  follows  that  we  will  have  neither  the  space  nor  the  time  to  characterize 

any  one  of  them  completely;  besides,  it  would  be  rather  boring  to  recite 

so  many  technical  rules.  The  best  way  to  grasp  the  spirit  of  a programming 

language  is  to  read  example  programs,  so  we  shall  adopt  the  following 

strategy:  A certain  fixed  algorithm  — which  we  shall  call  the  "TPK 

*/ 

algorithm"  for  want  of  a better  name-7  --  will  be  expressed  as  a program  in 
each  language  we  discuss.  Informal  explanations  of  this  program  should 
then  suffice  to  capture  the  essence  of  the  corresponding  language, 
although  the  TPK  algorithm  will  of  course  not  exhaust  that  language's 
capabilities;  once  we  have  understood  the  TPK  program,  we  will  be  able 
to  discuss  the  most  important  language  features  it  does  not  reveal. 

Note  that  the  same  algorithm  will  be  expressed  in  each  language, 
in  order  to  provide  a simple  means  of  comparison.  A serious  attempt 
has  been  made  to  write  each  program  in  the  style  originally  used  by  the 
author  of  the  corresponding  language;  and  if  comments  appear  next  to  the 
program  text,  they  attempt  to  match  the  terminology  used  at  that  time 
by  the  original  authors.  Our  treatment  will  therefore  be  something 
like  "a  recital  of  Chopsticks  as  it  would  have  been  played  by  Bach, 
Beethoven,  Brahms,  and  Brubeck."  The  resulting  programs  are  not  truly 
authentic  excerpts  from  the  historic  record,  but  they  will  serve  as 
fairly  close  replicas;  the  interested  reader  can  pursue  each  language 
further  by  consulting  the  bibliographic  references  to  be  given. 

The  exemplary  TPK  algorithm  which  we  shall  be  using  so  frequently 
can  be  written  as  follows  in  a dialect  of  Algol  60. 


TPK:  ijrt^eger  i;  real  y;  real  array  a[0:10] ; 

real  procedure  f(t);  real  t;  value  t; 

f :=  sqrt(abs(t) ) + 5 X t t 3 ; 
for  i :=  0 step  1 until  10  do  read(a[i] ) ; 
for  i :=  10  step  -1  untjll  0 do 
begin  y :=  f(a[i] ) ; 

if  y > U00  then  write(i,"T00  LARGE") 
else  write(i,y); 
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Cf.  "Grimm's  Law"  in  comparative  linguistics,  and/or  the  word  "typical", 
and/or  the  names  of  the  authors  of  this  article. 
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(Actually  Algol  60  is  not  one  of  the  languages  we  shall  he  discussing, 
since  it  was  a later  development,  hut  the  reader  ought  to  know  enough 
about  it  to  understand  TPK.  If  not,  here  is  a brief  run-down  on  what 
the  above  program  means:  Line  1 says  that  i is  an  integer-valued 

variable,  while  y takes  on  floating-point  approximations  to  real 
values;  and  aQ, a-^,  •••>aqo  are  also  real  valued.  Lines  2 and  3 define 

the  function  f(t)  = V|t|  + 5t^  , for  use  in  the  algorithm  proper 
which  starts  on  line  4.  Line  4 reads  in  the  values  a^,  aq> • • •, a^Q  > 
in  this  order;  then  line  5 says  to  do  lines  6,  7 > 8,  9 (delimited  by 
begin  and  end  ) for  i = 1 0,  9>  ...,0  , in  that  order.  The  latter 
lines  cause  y to  be  set  to  f(a^)  , and  then  one  of  two  messages  is 
written  out.  The  message  is  either  the  current  value  of  i followed 
by  the  words  "TOO  LARGE"  , or  the  current  values  of  i and  y , 
according  as  y > 400  or  not . ) 

Of  course  this  algorithm  is  quite  useless;  but  for  our  purposes 
it  will  be  helpful  to  imagine  ourselves  vitally  interested  in  the  process. 
Let  us  pretend  that  the  function  f(t)  = + 5t^  has  a tremendous 

practical  significance,  and  that  it  is  extremely  important  to  print  out 
the  function  values  f(a^)  in  the  opposite  order  from  which  the  a^ 
are  received.  This  will  put  us  in  the  right  frame  of  mind  to  be  reading 
the  programs,  (if  a truly  useful  algorithm  were  being  considered  here, 
it  would  need  to  be  much  longer  in  order  to  illustrate  as  many  different 
programming  language  features . ) 

Many  of  the  programs  we  shall  discuss  will  have  italicized  line 
numbers  in  the  left-hand  margin,  as  in  the  Algol  code  above.  Such  numbers 
are  not  really  part  of  the  programs,  they  appear  only  so  that  the 
accompanying  text  can  refer  easily  to  any  particular  line. 

It  turns  out  that  most  of  the  early  high-level  languages  were 
incapable  of  handling  the  TPK  algorithm  exactly  as  presented  above; 
so  we  must  make  some  modifications.  In  the  first  place,  when  a language 
deals  only  with  integer  variables,  we  shall  assume  that  all  inputs  and 
outputs  are  integer  valued,  and  that  " sqrt(x)  " denotes  the  largest 
integer  not  exceeding  /x  . Secondly,  if  the  language  does  not  provide 
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for  alphabetic  output,  the  string  "TOO  LARGE"  will  be  replaced  by  the 

number  999  • Thirdly,  some  languages  do  not  provide  for  input  and 

output  at  all;  in  such  a case,  we  shall  assume  that  the  input  values 

aQ,  a^, . . ,,a^Q  have  somehow  been  supplied  by  an  external  process,  and 

that  our  job  is  to  compute  22  output  values  bQ,b^,  . . -,b21  • Here 

b0,b2, . . .,bg0  will  be  the  respective  " i values"  10,9>--->0  , and  the 

alternate  positions  b^ ,b,, . . .,bn1  will  contain  the  corresponding  f (a. ) 

-L  dl.  1 

values  and/or  999  codes.  Finally,  if  a language  does  not  allow  the 
programmer  to  define  his  own  functions,  the  statement  " y :=  f(a[i])  " 
will  essentially  be  replaced  by  its  expanded-out  form 
" y :=  sqrt(abs(a[i] ) ) + 5 X a[i]  T 3 " • 

Prior  developments. 


Before  getting  into  real  programming  languages,  let  us  try  to  set 
the  scene  by  reviewing  the  background  very  quickly.  How  were  algorithms 
described  prior  to  19^5? 

The  earliest  known  written  algorithms  come  from  ancient  Mesopotamia, 
about  2000  B.C.  In  this  case  the  written  descriptions  contained  only 
sequences  of  calculations  on  particular  sets  of  data,  not  an  abstract 
statement  of  the  procedure;  it  is  clear  that  strict  procedures  were 
being  followed  (since,  for  example,  multiplications  by  1 were  explicitly 
performed),  but  they  never  seem  to  have  been  written  down.  Iterations 
like  " for  i :=  0 step  1 until  10  " were  rare,  but  when  present  they 
would  consist  of  a fully-expanded  sequence  of  calculations.  (See  [KN  72], 
for  a survey  of  Babylonian  algorithms.) 

By  the  time  of  Greek  civilization,  several  nontrivial  abstract 
algorithms  had  been  studied  rather  thoroughly;  for  example,  see  [KN  69, 
p.  295]  for  a paraphrase  of  Euclid's  presentation  of  "Euclid's  algorithm". 
The  description  of  algorithms  was  always  informal,  however,  rendered 
in  natural  language. 

During  the  ensuing  centuries,  mathematicians  never  did  invent  a 
good  notation  for  dynamic  processes,  although  of  course  notations  for 
(static)  functional  relations  became  highly  developed.  When  a procedure 
involved  nontrivial  sequences  of  decisions,  the  available  methods  for 
precise  description  remained  informal.  and  rather  cumbersome. 
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Example  programs  written  for  early  computing  devices,  such  as  those 
for  Babbage's  Calculating  Engine,  were  naturally  presented  in  "machine 
language"  rather  than  ir.  a true  programming  language.  Thus:  (a)  The 

three-address  code  for  Babbage's  machine  was  to  consist  of  instructions 
such  as  " x VQ  = ",  where  operation  signs  like  " x"  would  appear 

on  an  Operation-card,  and  subscript  numbers  like  (k  , 0 , 10)  would  appear 
on  a separate  Variable-card.  The  most  elaborate  program  developed  by 
Babbage  and  Lady  Lovelace  for  this  machine  was  a routine  for  calculating 
Bernoulli  numbers;  see  [BA  6l,  pp.  68,  286-297]*  (h)  In  191  *+>  Leonardo 

Torres  y Quevedo  used  natural  language  to  describe  the  steps  of  a short 
program  for  his  hypothetical  automaton;  and  Helmut  Schreyer  gave  an 
analogous  description  in  1939  for  the  machine  he  had  helped  Konrad  Zuse 
to  build  [see  RA  73,  pp.  95-98,  167].  (c)  An  example  MARK  I program 
given  in  19^6  by  Howard  Aiken  and  Grace  Hopper  [see  RA  73,  pp.  216-218] 
shows  that  its  machine  language  was  considerably  more  complicated. 

Although  all  of  these  early  programs  were  in  a machine  language, 
it  is  interesting  to  note  that  Babbage  had  noticed  already  on  July  9>  1836 
that  machines  as  well  as  people  could  produce  programs  as  output: 

This  day  I had  for  the  first  time  a general  but  very  indistinct 
conception  of  the  possibility  of  making  an  engine  work  out  algebraic 
developments.  I mean  without  any  reference  to  the  value  of  the 
letters.  My  notion  is  that  as  the  cards  (jacquards)  of  the 
Calc,  engine  direct  a series  of  operations  and  then  recommence 
with  the  first  so  it  might  perhaps  be  possible  to  cause  the  same 
cards  to  punch  others  equivalent  to  any  given  number  of  repetitions. 
But  there  hole  [sic]  might  perhaps  be  small  pieces  of  formulae 
previously  made  by  the  first  cards.  [RA73,  p.  3U9] 

To  conclude  this  survey  of  prior  developments,  let  us  take  a look  at 
A.  M.  Turing's  famous  mathematical  paper  of  1936  [TU  36],  where  the 
concept  of  a universal  computing  machine  was  introduced  for  theoretical 
purposes.  Turing's  machine  language  was  more  primitive,  not  having  a 
built-in  arithmetic  capability,  and  he  defined  a complex  program  by 
giving  what  amounts  to  macro- expans ions  or  open  subroutines.  For  example, 
here  was  his  program  for  making  the  machine 
its  working  tape: 

6 


m-config. 

symbol 

behavior 

final  m-config 

£(C,B,a) 

f 3 

L 

£l(C,  B,a) 

( 

- ~ ~ 

j not  a 

L 

f(C,  B,  a) 

f" 

C 

£l(C,B,a)  ( 

not  a 

| 

R 

£l(C,B,a) 

None 

R 

f2(C,B,a) 

j 

r a 

C 

£2(C,B,a)  < 

not  a 

R 

£l(C,  B,a) 

L None 

R 

B 

. 


[In  order  to  carry  out  this  operation,  one  sends  the  machine  to  state 
f(C, B,  a)  ; it  will  immediately  begin  to  scan  left  (L)  until  first 

passing  the  symbol  s . Then  it  moves  right  until  either  encountering 
the  symbol  a or  two  consecutive  blanks;  in  the  first  case  it  enters 
into  state  C while  still  scanning  the  a , and  in  the  second  case  it 
enters  state"  B after  moving  to  the  right  of  the  second  blank.  Turing 
used  the  term  ~ "m-configuration"  for  state.] 

Such  "skeleton  tables",  as  presented  by  Turing,  represented  the 
highest-level  notations  for  precise  algorithm  description  that  were 
developed  before  our  story  begins  — except,  perhaps,  for  Alonzo  Church's 
"\-notation"  [CH  36]  which  represents  an  entirely  different  approach  to 
calculation.  Mathematicians  would  traditionally  present  the  control 
mechanisms  of  algorithms  informally,  and  the  computations  involved  would 
be  expressed  by  means  of  equations.  There  was  no  concept  of  assignment 
(i.e.,  of  replacing  the  value  of  some  variable  by  a new  value);  instead 
of  writing  " s < — s " one  would  write  sn+p  ~ ~sn  ’ Saving  a new  name  to 
each  quantity  that  would  arise  during  a sequence  of  calculations. 

_Zu ] 'Plane ale ulun " . 

Near  the  end  of  World  War  II,  Allied  bombs  destroyed  nearly  all  of 
the  sophisticated  relay  computers  that  Konrad  Zuse  had  been  building  in 
Germany  since  1936.  Only  his  Z4  machine  could  be  rescued,  in  what  Zuse 
describes  as  a fantastic  ["abenteuerlich" ] way;  and  he  moved  the  zX  to 
a little  shed  in  a small  Alpine  village  called  Hinterstein. 

It  was  unthinkable  to  continue  practical  work  on  the  equipment; 
my  small  group  of  twelve  co-workers  disbanded.  But  it  was  now  a 
satisfactory  time  to  pursue  theoretical  studies.  The  ZX  Computer 
which  had  been  rescued  could  barely  be  made  to  run,  and  no 
especially  algorithmic  language  was  really  necessary  to  program 
it  anyway.  [Conditional  commands  had  consciously  been  omitted; 
see  [RA  73,  p.  l8l ] . ] Thus  the  PK  [ Plankalkul ] arose  purely  as  a 
piece  of  desk- work,  without  regard  to  whether  or  not  machines 
suitable  for  PK' s programs  would  be  available  in  the  foreseeable 
future.  [ZU72,  p.  6]. 
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Zuse  had  previously  come  to  grips  with  the  lack  of  formal  notations 

for  algorithms  while  working  on  his  planned  doctoral  dissertation 

[ZU  11] . Here  he  had  independently  developed  a three-address  notation 

remarkably  like  that  of  Babbage;  for  example,  to  compute  the  roots 
2 

and  Xg  of  x + ax  + b = 0 , given  a = and  b = Vg  , he 
prepared  the  following  Rechenplan  [p.  26]: 

Vl:2  =V3 
VV3  “VU 
VV2  = V5 

^5  =V6 
v5(-D  =V? 

VV6  = V8=xl 

V7-V6=V9=x2 


He  realized  that  this  notation  was  limited  to  straight-line  programs 

[so-called  star re  Plane],  and  he  concluded  his  previous  manuscript  with 
the  following  remark: 

Unstarre  Rechenplane  constitute  the  true  discipline  of  higher 
combinatorial  computing;  however,  they  cannot  yet  be  treated  in 
this  place.  [ZU  14,  p.  31] 

The  completion  of  this  work  was  the  theoretical  task  Zuse  set  himself 
in  1915,  and  he  pursued  it  very  energetically.  The  result  was  an  amazingly 
comprehensive  language  which  he  called  the  Plankalkul  [program  calculus], 
an  extension  of  Hilbert's  Aussagenkalkul  [propositional  calculus]  and 
Pradikatenkalkul  [predicate  calculus].  Before  laying  this  project  aside, 
Zuse  had  completed  an  extensive  manuscript  containing  programs  far  more 
complex  than  anything  ever  written  before.  Among  other  things,  there  were 
algorithms  for  sorting;  for  testing  the  connectivity  of  a graph  represented 
as  a li.t  'f  edges;  for  integer  arithmetic  (including  square  roots)  in 
binary  r,  ••i*;:>n;  and  for  floating-point  arithmetic.  He  even  developed 


■ , — ... ...... 


algorithms  to  test  whether  or  not  a given  logical  formula  is  syntactically 
well-formed.,  and  whether  or  not  such  a formula  contains  redundant 
parentheses  — assuming  six  levels  of  precedence  between  the  operators. 

To  top  things  off,  he  also  included  h-9  pages  of  algorithms  for  playing 
chess.  (Who  would  have  believed  that  such  pioneering  developments 
could  emerge  from  the  solitary  village  of  Hinterstein?  His  plans  to 
include  algorithms  for  matrix  calculations,  series  expansions,  etc., 
had  to  be  dropped  since  the  necessary  contacts  were  lacking  in  that 
place;  furthermore,  his  chess  playing  program  treated  "en  passant 
captures"  incorrectly,  because  he  could  find  no  chess  boards  or  people 
to  play  chess  with  [ZU  72,  pp.  32,  35] 0 

Zuse's  19^5  manuscript  unfortunately  lay  unpublished  until  1972, 
although  brief  excerpts  appeared  in  1948  and  1959  [ZU  48,  ZU  59]  j see  also 
[BW72],  where  his  work  was  brought  to  the  attention  of  English-speaking 
readers  for  the  first  time.  It  is  interesting  to  speculate  about  what 
would  have  happened  if  he  had  published  everything  at  once;  would  many 
people  have  been  able  to  understand  such  radical  new  ideas? 

The  monograph  [ZU  45]  on  Plankalkul  begins  with  the  following 
statement  of  motivation: 

Aufgabe  des  Plankalkuls  ist  es,  beliebige  Rechenvorschriften  rein 
formal  darzustellen.  [The  mission  of  the  Plancalculus  is  to 
provide  a purely  formal  description  of  any  computational  procedure . ] 

So,  in  particular,  the  Plankalkul  should  be  able  to  describe  the  TPK 
algorithm;  and  we  had  better  turn  now  to  this  program,  before  we  forget 
what  TPK  is  all  about.  Zuse's  notation  may  appear  somewhat  frightening 
at  first,  but  we  will  soon  see  that  it  is  really  not  difficult  to  understand. 
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Line  1 of  this  code  is  the  declaration  of  a compound  data  type,  and 
before  we  discuss  the  remainder  of  the  program  we  should  stress  the  richness 
of  data  structures  provided  by  Zuse's  language  (even  in  its  early  form 
[ZU  1+1+]).  This  is,  in  fact,  one  of  the  greatest  strengths  of  the 
Planka.1  kul ; none  of  the  other  languages  we  shall  discuss  had  such  a 
perceptive  notion  of  data,  yet  Zuse’s  proposal  was  simple  and  elegant. 

He  started  with  data  of  type  SO  , a single  bit  ["Ja-Nein-Wert"]  whose 
value  is  either  " or  "+".  From  any  given  data  types  aQ,  . . . , cr^  ^ , 
a programmer  could  define  the  compound  data  type  (oQ,  > and 
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individual  components  of  this  compound  type  could  be  referred  to  by 
applying  the  subscripts  0 , ...  , k-1  to  any  variable  of  that  type. 

Arrays  could  also  be  defined  by  writing  m x ° , meaning  m identical 
components  of  type  a ; and  this  idea  could  be  repeated,  in  order  to 
obtain  arrays  of  any  desired  dimension.  Furthermore  m could  be 
meaning  a list  of  variable  length,  and  Zuse  made  good  use  of  such  list 
structures  in  his  algorithms  dealing  with  graphs,  algebraic  formulas,  and 
che s splay . 

Thus  the  Plankalkul  included  the  important  concept  of  hierarchically 
structured  data,  going  all  the  way  down  to  the  bit  level.  Such  advanced 
data  structures  did  not  enter  again  into  programming  languages  until  the 
late  1950's,  in  IBM's  Commercial  Translator.  The  idea  eventually 
appeared  in  many  other  languages,  such  as  FACT,  COBOL,  PL/ I,  and 
extensions  of  ALGOL  60;  cf.  [CL  6l]  and  [SA  69,  p.  325]. 

Integer  variables  in  the  Plankalkul  were  represented  by  type  A9  . 
Another  special  type  was  used  for  floating-binary  numbers,  namely 

All  = (3  x SO  , 7 x SO  , 22  x SO)  . 


The  first  three-bit  component  here  was  for  signs  and  special  markers  — 
indicating,  for  example,  whether  the  number  was  real  or  imaginary  or  zero;  the 
second  was  for  a seven-bit  exponent  in  two's  complement  notation;  and 
the  final  22  bits  represented  the  23 -bit  fraction  part  of  a normalized  number, 
with  the  redundant  leading  " 1"  bit  suppressed.  Thus,  for  example,  the 
floating-point  number  +400.0  would  have  appeared  as 

(_+.  , ■+ , +--+)  , 

and  it  also  could  be  written 

(LO  , L000  , LOOLOOOOOOOOOOOOOOOOOO)  . 

[The  + 's  and  - 's  notation  has  its  bits  numbered  0,1, ...  from  left-to- 
right,  while  the  L ' s and  0 ' s notation  corresponds  to  the  more  familiar 
binary  notation,  putting  most  significant  bits  at  the  left.]  There  was  a 
special  representation  for  "infinite"  and  "very  small"  and  "undefined" 
quantities;  for  example, 
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Note  that  the  above  program  uses  + °°  instead  of  999  on  line  15,  since 
such  a value  seems  an  appropriate  way  to  render  the  concept  "TOO  LARGE"  . 

Let  us  return  now  to  the  program  itself.  Line  1 introduces  the  data 
type  A2  , namely  an  ordered  pair  whose  first  component  is  an  integer 
(type  A9  ) and  whose  second  component  is  floating-point  (type  AAl  ). 

This  data  type  will  be  used  later  for  the  11  outputs  of  the  TPK  algorithm. 
Lines  2 thru  define  the  function  f(t)  , and  lines  8 thru  22  define  the 
main  TPK  program. 

The  hardest  thing  to  get  used  to  about  Zuse's  notation  is  the  fact 

that  each  operation  spans  several  lines;  for  example,  lines  11  thru  14  must 

be  read  as  a unit.  The  second  line  of  each  group  (labelled  " V")  is  used 

to  identify  the  subscrip+s  for  quantities  named  on  the  top  line;  thus 

R , V , Z stands  for  e variables  R0  , V0  , Z0  . Operations  are  done 
0 0 0 

primarily  on  output  variables  ["Resultatwerte" ] , input  variables 

["Variablen" ] Vk  , and  intermediate  variables  ["Zwischenwerte" ] Z^  . 

The  " K"  line  is  used  to  denote  components  of  a variable,  so  that,  in 

our  example,  V means  component  i of  the  input  variable  V„  . 

0 

i 

(A  completely  blank  " K"  line  is  normally  omitted.)  Complicated  subscripts 
can  be  handled  by  making  a zig-zag  bar  from  the  K-line  up  to  the  top  line, 
as  in  line  1 of  the  above  program  where  the  notation  indicates  component 
10- i of  Rq  . The  bottom  line  of  each  group  is  labeled  A or  S , and 
it  is  used  to  specify  the  type  of  each  variable.  Thus  the  " 2 " in  line  18 
of  our  example  means  that  Rq  is  of  type  A2  ; the  " Al  " means  that  Zq 
is  floating-point  (type  AAl  ) ; and  the  " 9 " means  that  i is  an  integer. 
Thus  each  " A"  in  the  left  margin  is  implicitly  attached  to  all  types  in 
its  line. 

Zuse  remarked  [ZU  45,  p.  10]  that  the  number  of  possible  data  types 
was  so  large,  it  would  be  impossible  to  indicate  a variable's  type  simply 
by  using  typographical  conventions  as  in  classical  mathematics;  thus  he 
realized  the  importance  of  apprehending  the  type  of  ea -h  variable  at 
each  point  of  a program,  although  this  information  is  usually  redundant. 
This  is  probably  one  of  the  main  reasons  he  introduced  the  peculiar 
multi-line  format.  Incidentally,  a somewhat  similar  multi-line  notation 
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has  been  used  in  recent  years  to  describe  musical  notes  [SM  73] j it  is 
interesting  to  speculate  if  this  notation  will  evolve  in  the  same  way 
that  programming  languages  have. 

We  are  now  ready  to  penetrate  further  into  the  meaning  of  the  above 
code.  Each  plan  begins  with  a specification  part  ["Randauszug"],  stating 
the  types  of  all  inputs  and  outputs.  Thus,  lines  2 thru  4 mean  that  PI 
is  a procedure  that  takes  an  input  Vq  of  type  AAl  (floating  point)  and 
produces  Rq  of  the  same  type.  Lines  8 thru  10  say  that  P2  maps  Vq  of 
type  11  x AAl  (namely,  a vector  of  1 floating-point  numbers,  the  array  ai 
of  our  TPK  algorithm)  into  a result  Rq  of  type  11  xA2  (namely,  a vector 
of  11  ordered  pairs  as  described  earlier). 

The  double  arrow  , which  Zuse  called  the  Ergibt-Zeichen  (yields-sign), 
was  introduced  for  the  assignment  operation;  thus  the  meaning  of  lines  5 
thru  should  be  clear.  As  we  have  remarked,  mathematicians  had  never 
used  such  an  operator  before;  in  fact,  the  systematic  use  of  assignments 
constitutes  a distinct  break  between  computer- science  thinking  and 
mathematical  thinking.  Zuse  consciously  introduced  a new  symbol  for  the 

new  operation,  remarking  [ZU  45,  p.  15]  that  Z + l =>  Z was  analogous  to 

3 3 

to  the  more  traditional  equation  Z + 1 = Z . (incidentally,  the 

3.i  3.i+l 

publishers  of  [ZU  48]  used  the  sign  >=  instead  of  =s  , but  Zuse  never 
actually  wrote  >=  himself. ) Note  that  the  variable  receiving  a new  value 
appears  on  the  right,  while  most  present-day  languages  have  it  on  the  left. 

We  shall  see  that  there  was  a gradual  "leftist"  trend  as  languages 
developed. 

It  remains  to  understand  lines  11  thru  22  of  the  example.  The  notation 
" W2(n)  " represents  an  iteration,  for  i = n-1  down  to  0 , inclusive; 
hence  W2(ll)  stands  for  the  second  for  loop  in  the  TPK  algorithm. 

(The  index  of  such  an  iteration  was  always  denoted  by  i , or  i.O  ; if 
another  iteration  were  nested  inside,  its  index  would  be  called  i.l  , 
etc.)  The  notation  Rl(x)  on  line  11  stands  for  the  result  Rq  of 

applying  procedure  PI  to  input  x . Lines  15_  thru  18  of  the  program  mean 
" if)  Zq  > 400  then  RQ[10-i]  :=  (i  , +<*>)  ";  note  Zuse's  new  notation  y 
for  conditionals.  Lines  1£  thru  22  are  similar,  the  bar  over  " Zq  > 400  " 
indicating  the  negation  of  that  relation.  There  was  no  equivalent  of 
" else  " in  the  Plankalkiil,  nor  were  there  go  to  statements.  Zuse  did, 
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however,  have  the  notation  " Fin  " with  superscripts,  to  indicate  a 
jump  out  of  a given  number  of  iteration  levels  and/or  to  the  beginning 
of  a new  iteration  cycle  [cf.  ZU  72,  p.  28;  ZU  1+5,  p.  32];  this  idea 
has  recently  been  revived  in  the  BLISS  language  [WR  71] . 

The  reader  should  now  be  able  to  understand  the  above  code  completely. 
In  the  text  accompanying  his  programs  in  Plankalkul  notation,  Zu6e 
made  it  a point  to  state  also  the  mathematical  relations  between  the 
variables  which  appeared.  He  called  such  a relation  an  impliciter  Ansatz; 
we  would  now  call  it  an  "invariant”.  This  was  yet  another  fundamental 
idea  about  programming;  and,  like  Zuse's  data  structures,  it  disappeared 
from  programming  languages  during  the  1950' s,  waiting  to  be  enthusiastically 
received  when  the  time  was  ripe  [HO  71] . 

Zuse  had  visions  of  using  the  Plankalkul  some  day  as  the  basis  of  a 
programming  language  that  could  be  translated  by  machine  (cf.  [ZU  72, 
pp.  5,  18,33,  3^])j  "but  in  19^+5,  he  was  considering  first  things  first 
— namely,  he  needed  to  decide  what  concepts  should  be  embodied  in  a 
notation  for  programming.  We  cam  summarize  his  accomplishments  by 
saying  that  the  Plankalkul  incorporated  many  extremely  important  ideas,  but 
it  lacked  the  "syntactic  sugar"  for  expressing  programs  in  a readable 
and  easily  writable  format. 

Zuse  says  he  made  modest  attempts  in  later  years  to  have  the 
Plankalkul  implemented  within  his  own  company,  "but  this  project 
necessarily  foundered  because  the  expense  of  implementing  and  designing 
compilers  outstripped  the  resources  of  my  small  firm."  He  also  mentions 
his  disappointment  that  more  of  the  ideas  of  the  Plankalkul  were  not 
incorporated  into  Algol  58,  since  some  of  Algol's  original  designers 
knew  of  his  work.  [ZU  72,  p.  7]  Such  an  outcome  was  probably  inevitable, 
because  the  Plankalkul  was  far  ahead  of  its  time  from  the  standpoint  of 
available  hardware  and  software  development.  Most  of  the  other  languages 
we  shall  discuss  started  at  the  other  end,  by  asking  what  was  possible 
to  implement  rather  than  what  was  possible  to  write;  and  it  naturally 
took  many  years  for  these  two  approaches  to  come  together  and  to  achieve 
a suitable  synthesis. 
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Flow  Diagrams. 


On  the  other  side  of  the  Atlantic,  Herman  H.  Goldstine  and  John 
von  Neumann  were  wrestling  with  the  same  sort  of  problem  that  Zuse  had 
faced:  How  should  algorithms  be  represented  in  a precise  way,  at  a 

higher  level  than  the  machine's  language?  Their  answer,  which  was  due 
in  large  measure  to  Goldstine' s analysis  of  the  problem  together  with 
suggestions  by  von  Neumann,  Adele  Goldstine,  and  Arthur  W.  Burks  [GO  72, 
pp.  266-268],  was  quite  different  from  the  Plankalkul:  they  proposed  a 

pictorial  representation  involving  boxes  joined  by  arrows,  and  they  called 
it  a "flow  diagram".  During  19^6  and  19^7  they  prepared  an  extensive 
and  carefully  worked  out  treatise  on  programming  based  on  the  idea  of 
flow  diagrams  [GV  U7],  and  it  is  interesting  to  compare  this  work  to 
that  of  Zuse.  There  are  striking  differences,  such  as  an  emphasis  on 
numerical  calculation  rather  than  on  data  structures;  and  there  are  also 
striking  parallels,  such  as  the  use  of  the  term  "Plan"  in  the  titles  of 
both  documents.  Although  neither  work  was  published  in  contemporary 
journals,  perhaps  the  most  significant  difference  was  that  the  treatise 
of  Goldstine  and  von  Neumann  was  beautifully  "Varityped"  and  distributed 
in  quantity  to  the  vast  majority  of  people  involved  with  computers  at 
that  time.  This  fact,  coupled  with  the  high  quality  of  presentation  and 
von  Neumann's  prestige,  meant  that  their  report  had  an  enormous  impact, 
forming  the  foundation  for  computer  programming  techniques  all  over  the 
world.  The  term  "flow  diagram"  became  shortened  to  "flow  chart"  and 
eventually  it  even  became  "flowchart"  — a word  which  has  entered  our 
language  as  both  noun  and  verb. 

We  all  know  what  flowcharts  are;  but  comparatively  few  people  have 
seen  an  authentic  original  flow  diagram.  In  fact,  it  is  very  instructive 
to  go  back  to  the  original  style  of  Goldstine  and  von  Neumann,  since 
their  inaugural  flow  diagrams  represent  a transition  point  between  the 
mathematical  "equality"  notation  and  the  computer- science  "assignment" 
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Several  things  need  to  he  explained  about  this  original  notation, 

and  probably  the  most  important  consideration  is  the  fact  that  the  boxes 

containing  " 10  ->  i " and  " i-1  - i " were  not  intended  to  specify  any 

computation.  This  amounts  to  a significantly  different  viewpoint  than 

we  are  now  accustomed  to,  and  the  reader  will  find  it  worthwhile  to 

ponder  this  conceptual  difference  until  he  or  she  understands  it.  The 

box  " i-1  -*  i " represents  merely  a change  in  notation,  as  the  flow 

of  control  passes  that  point,  rather  than  an  action  to  be  performed  by 

the  computer.  For  example,  box  VII  has  done  the  computaticn  necessary 
-59/ 

to  place  2 (i-1)  into  storage  position  C.l  ; so  after  we  pass  the 

box  " i-1  -*  i " and  go  thru  the  subsequent  junction  point  to  box  II, 
location  C.l  now  contains  . The  external  notation  has  changed 

but  location  C.l  has  noti  This  distinction  between  external  and  internal 
notations  occurs  throughout,  the  external  notation  being  problem-oriented 
while  the  actual  contents  of  memory  are  machine-oriented.  The  numbers 
attached  to  each  arrow  in  the  diagram  indicate  so-called  "constancy 
intervals",  where  all  memory  locations  have  constant  contents  and  all 
bound  variables  of  the  external  notation  have  constant  meaning. 

A "storage  table"  is  attached  by  a dashed  line  to  the  constancy  intervals, 
to  show  the  relevant  relations  between  external  and  internal  values  at 
that  point.  Thus,  for  example,  we  note  that  the  box  " 10  — i " does 
not  specify  any  computation,  but  it  provides  the  appropriate  transition 
frctn  constancy  interval  1.5  to  constancy  interval  2 . (Cf.  [GV  U7, 

§§  7.6,  7.7].) 

There  were  four  kinds  of  boxes  in  a flow  diagram:  (a)  Operation 

boxes,  marked  with  a Roman  numeral;  this  is  where  the  computer  program 
was  supposed  to  make  appropriate  transitions  in  storage,  (b)  Alternative 
boxes,  also  marked  with  a Roman  numeral,  and  having  two  exits  marked  + 
and  - ; this  is  where  the  computer  control  was  to  branch,  depending  on 
the  sign  of  the  named  quantity,  (c)  Substitution  boxes,  marked  with  a 
# and  using  the  " -*  " symbol;  this  is  where  the  external  notation  for 
a bound  variable  changed,  as  explained  above,  (d)  Assertion  boxes,  also 
marked  with  a # ; this  is  where  important  relations  between  external 
notations  and  the  current  state  of  the  control  were  specified.  The 
example  chows  three  assertion  boxes,  one  which  says  " i = -1  ",  and  two 
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which  assert  that  the  outputs  u_^  and  (in  a problem-oriented 

notation)  now  have  certain  values.  Like  substitution  boxes,  assertion 
boxes  did  not  indicate  any  action  by  the  computer,  they  merely  stated 
relationships  which  helped  to  prove  the  validity  of  the  program  and 
which  might  help  the  programmer  to  write  code  for  the  operation 
boxes . 

The  next  most  prominent  feature  about  original  flow-diagrams  is 

the  fact  that  a programmer  was  required  to  be  conscious  of  the  scaling 

(i.e.,  the  binary  point  location)  of  all  numbers  in  the  computer  memory. 

A computer  word  was  1+0  bits  long  and  its  contents  was  to  be  regarded  as  a binary 

fraction  x in  the  range  -1  < x < 1 . Thus,  for  example,  the  above 

flowchart  assumes  that  2 10a . is  initially  present  in  storage  position 

A.j  , rather  than  the  value  a.  itself;  and  the  output?  b.  are 

J o 

similarly  scaled. 

The  final  mystery  which  needs  to  be  revealed  is  the  meaning  of 

notations  such  as  (a+i)Q  > (b)0  ’ etc‘  In  general>  " x0  " was  used 

when  x was  an  integer  machine  address;  and  it  represented  the  number 
-19  _xo 

2 ^x  + 2 x , namely  a binary  word  with  x appearing  twice,  in  bit 
positions  9 to  20  and  29  to  1+0  (counting  from  the  left).  Such  a 
number  could  be  used  in  their  machine  to  modify  the  addresses  of  20-bit 
instructions  that  appeared  in  either  half  of  a 1+0-bit  word. 

Once  a flow  diagram  such  as  this  had  been  drawn  up,  the  remaining 
task  was  to  prepare  so-called  "static  coding"  for  boxes  marked  with 
Roman  numerals.  In  this  task  a programmer  would  use  his  problem-solving 
ability,  together  with  his  knowledge  of  machine  language  and  the 
information  from  storage  tables  and  assertion  boxes,  to  make  the  required 
transitions.  For  example,  in  box  VI  one  should  use  the  facts  that  u^  = i , 
that  storage  D contains  2 > that  storage  C.l  contains  2”^i  , 

and  that  storage  C.3  contains  (b+20-2i)Q  [a  word  corresponding  to 
the  location  of  variable  B.20-2i  ] to  carry  out  the  specified  assignments. 

The  job  of  box  VII  is  slightly  trickier:  One  of  the  tasks,  for  example, 

is  to  store  (b  + 22  -2i)n  in  location  C.3  ; the  programmer  was  supposed 
to  resolve  this  by  adding  2* (2  +2  to  the  previous  contents  of  C.3  . 

In  general,  the  job  of  static  coding  required  a fairly  high  level  of 
artificial  intelligence,  and  ii,  was  far  beyond  the  state  of  the  art  in 
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in  those  days  to  get  a computer  to  do  such  a thing.  As  with  the 
Plankalkiil,  the  notation  needed  to  he  simplified  if  it  was  to  he 
suitable  for  machine  implementation. 

Let  us  make  one  final  note  about  flow  diagrams  in  their  original 
form:  Goldstine  and  von  Neumann  did  not  suggest  any  notation  for 

subroutine  calls,  hence  the  function  f(t)  in  the  TPK  algorithm  has 
been  written  in-line.  In  [GV  47,  §12]  there  is  a flow  diagram  for 
the  algorithm  that  a loading  routine  must  follow  in  order  to  relocate 
subroutines  from  a library,  but  there  is  no  example  of  a flow  diagram 
for  a driver  program  that  calls  a subroutine.  An  appropriate  extension 
of  flow  diagrams  to  subroutine  calls  could  surely  be  made,  but  it  would 
have  made  our  example  less  "authentic". 

A Logician ' s Approach . 

Let  us  now  turn  to  the  proposals  made  by  Haskell  B.  Curry,  who  was 
working  at  the  Naval  Ordnance  Laboratory  in  Silver  Spring,  Maryland; 
his  activity  was  partly  contemporaneous  with  that  of  Goldstine  and 
von  Neumann,  since  the  last  portion  of  [GV  47]  was  not  distributed  until 
191*8. 

Curry  wrote  two  lengthy  memoranda  [CU  48,  CU  50 ] which  have  never 
been  published;  the  only  appearance  of  his  work  in  the  open  literature 
has  been  the  brief  and  somewhat  cryptic  summary  in  [CU  50'].  He  had 
prepared  a rather  complex  program  for  ENIAC  in  1946,  and  this  experience 
led  him  to  suggest  a notation  for  program  construction  that  is  more 
compact  than  flowcharts. 

His  aims,  which  correspond  to  important  aspects  of  what  we  now  call 
"structured  programming",  were  quite  laudable: 

The  first  step  in  planning  the  program  is  to  analyze  the  computation 
into  certain  main  parts,  called  here  divisions,  such  that  the 
program  can  be  synthesized  from  them.  Those  main  parts  must  be 
such  that  they,  or  at  any  rate  some  of  them,  are  independent 
computations  in  their  own  right,  or  are  modifications  of  such 
computations.  [CU  50,^  54] 
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But  in  practice  his  proposal  was  not  especially  successful,  because 
the  way  he  factored  a problem  was  not  very  natural;  his  components 
tended  to  have  several  entrances  and  several  exits,  and  perhaps  Ms 
mathematical  abilities  tempted  him  too  strongly  to  pursue  the  complexities 
of  fitting  such  pieces  together.  As  a result,  the  notation  he  developed 
was  somewhat  eccentric;  and  the  work  was  left  unfinished.  Here  is  how 
he  might  have  represented  the  TPK  algorithm: 

F(t)  = {VJtj’  + 5t5:A} 

I = [10 :i}  - [t  - L(a+i) } - F(t)  - {A:y} 

- II  - lt?(0,i)  - o1&i2 

II  = (x  = L(b  +20  - 2i ) } - (i  :x]  - III 

-*  [w  = L(b  + 21  - 2i) } — [y :w} 

III  = {y  > 400]  - {999:y}&01 


The  following  explanations  should  suffice  to  make  the  example  clear, 
although  they  do  not  reveal  the  full  generality  of  his  language: 


{E:x}  means  "compute  the  value  of  expression  E and  store  it  in 
location  x ". 

A denotes  the  accumulator  of  the  machine. 

fx  = L(E)}  means  "compute  the  value  of  expression  E and  substitute 
it  into  n.1 1 appearances  of  ' x ' in  the  following  instruction 
groups" . 

X -*  Y means  "substitute  instruction  group  Y for  the  first  exit 
of  instruction  group  X " . 

I.  denotes  the  j-th  entrance  of  this  routine,  namely  the  beginning 
of  its  j-th  instruction  group. 

Oj  denotes  the  j-th  exit  of  this  routine  (he  used  the  words  "input" 
and  "output"  for  entrance  and  exit). 

(x  > y]  -«  O-^&Og  means  "if  x > y , go  to  0-^  , otherwise  to  0^ 

It^(m,  i)  -♦  O^&Og  means  "decrease  i by  1 , then  if  i > m go 
to  02  , otherwise  to  0^ 

Actually  the  main  feature  of  interest  in  Curry's  early  work  is  not 
this  programming  language,  but  rather  the  algorithms  he  discussed  for 


converting  parts  of  it  into  machine  language.  He  gave  a recursive 
description  of  a procedure  to  convert  fairly  general  arithmetic  expressions 
into  code  for  a one-address  computer,  thereby  being  the  first  person  to 
describe  the  code-generation  phase  of  a compiler.  (Syntactic  analysis 
was  not  specified;  he  gave  recursive  reduction  rules  analogous  to  well- 
known  constructions  in  mathematical  logic,  assuming  that  any  formula 
could  be  parsed  properly. ) His  motivation  for  doing  this  was  stated  in 

[cu  50' ]: 

Now  von  Neumann  and  Goldstine  have  pointed  out  that,  as  programs 
are  made  up  at  present,  we  should  not  use  the  technique  of  program 
composition  [i.e.,  subroutines]  to  make  the  simpler  sorts  of  programs 
--  these  would  be  programmed  directly  — but  only  to  avoid 
repetitions  in  programs  of  some  complexity.  Nevertheless,  there 
are  three  reasons  for  pushing  clear  back  to  formation  of  the 
simplest  programs  from  the  basic  programs  [i.e.,  machine  language 
instructions],  viz.:  (l)  Experience  in  logic  and  in  mathematics 
shows  that  an  insight  into  principles  is  often  best  obtained  by  a 
consideration  of  cases  too  simple  for  practical  use  --  e.g.,  one 
gets  an  insight  into  the  nature  of  a group  by  considering  the 
permutations  of  three  letters,  etc.  ...  (2)  It  is  quite  possible 

that  the  technique  of  program  composition  can  completely  replace 
the  elaborate  methods  of  Goldstine  and  von  Neumann;  while  this  may 
not  work  out,  the  possibility  is  at  least  worth  considering. 

(3)  The  technique  of  program  composition  can  be  mechanized;  if 
it  should  prove  desirable  to  set  up  programs,  or  at  any  rate  certain 
kinds  of  them,  by  machinery,  pre  sumably  this  may  be  done  by 
analyzing  them  clear  down  to  the  basic  programs. 

The  program  he  would  have  constructed  for  F(t)  , if  t ' were  replaced  by 
t*t*t  , is 

[ |t | : A}  - { /a  : A]  - [A:w]  - [t:R]  - (tR: A]  - {A:R}  - [tR: A] 

— [A:R]  -*  [3R:A]  -♦  [A+w:A] 

Here  w is  a temporary  storage  location,  and  R is  a register  used  in 
multiplication . 
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An  Algebraic  Interpreter. 

The  three  languages  we  have  seen  so  far  were  never  implemented;  they 
served  purely  as  conceptual  aids  during  the  programming  process.  Such 
conceptual  aids  were  obviously  important,  but  they  still  left  the 
programmer  with  a lot  of  mechanical  things  to  do,  and  there  were  many 
chances  for  errors  to  creep  in. 

The  first  "high-level"  programming  language  actually  to  be  implemented 
was  the  Short  Code,  originally  suggested  by  John  W.  Mauchly  in  I9U9. 

William  F.  Schmitt  coded  it  for  the  BINAC  at  that  time.  Late  in  1950, 
Schmitt  recoded  Short  Code  for  the  UNIVAC,  with  the  assistance  of 
Albert  B.  Tonik,  and  J.  Robert  Logan  revised  the  program  in  January  of  1952. 
Details  of  the  system  h?ve  never  been  published,  and  the  earliest 
extant  programmer's  manual  [RR  55]  seems  to  have  been  written  originally 
in  1952. 

The  absence  of  data  about  the  early  Short  Code  indicates  that  it 
was  not  an  instant  success,  in  spite  of  its  eventual  historic  significance. 
This  lack  of  popularity  is  not  surprising  when  we  consider  the  small 
number  of  scientific  users  of  UNIVAC  equipment  in  those  days;  in  fact, 
the  most  surprising  thing  is  that  an  algebraic  language  such  as  this  was 
not  developed  first  at  the  mathematically-oriented  centers  of  computer 
activity.  Perhaps  the  reason  is  that  mathematicians  were  so  conscious 
of  efficiency  considerations,  they  could  not  imagine  wasting  any  extra 
computer  time  for  something  a programmer  could  do  by  himself.  Mauchly 
had  greater  foresight  in  this  regard;  and  J.  R.  Logan  put  it  this  way: 

By  means  of  the  Short  Code,  any  mathematical  equations  may 
be  evaluated  by  the  mere  expedient  of  writing  them  down.  There 
is  a simple  symbological  transformation  of  the  equations  into 
code  as  explained  by  the  accompanying  write-up.  The  need  for 
special  programming  has  been  eliminated. 

In  our  comparisons  of  computer  time  with  respect  to  time 
consumed  by  manual  methods,  we  have  found  so  far  a speed  ratio 
of  at  least  fifty  to  one.  We  expect  better  results  from  future 
operations. 
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...  It  is  expected  that  future  use  of  the  Short  Code  will 
demonstrate  its  power  as  a tool  in  mathematical  research  and 
as  a checking  device  for  some  large-scale  problems.  [KR  55] 

We  cannot  be  certain  how  UNIVAC  Short  Code  looked  in  1950;  but 
it  probably  was  closely  approximated  by  the  1952  version,  when  TPK 
could  have  been  coded  in  the  following  way. 

Memory  equivalents:  i = WO  , t = TO  , y = YO  . 

Eleven  inputs  go  respectively  into  words  UO , T9  , T8  , . . . , TO  . 

Constants:  ZO  = 000000000000 

Z1  = 010000000051  [1.0  in  floating-decimal  form] 

Z2  = 010000000052  [10.0] 

Z5  = 040000000055  [4oo.o] 

z4  = AAATOOALARGE 

Z5  =050000000051  [5.0] 

Equation  number  recall  information  [labels]: 

0 = line  01  , 1 = line  06  , 2 = line  07 

Short  Code: 


Equations  Coded  representation 


00 

i 

= 10 

00 

00 

00 

wo 

03 

Z2 

01 

0: 

y 

= (/  abs  t)  + 5 cube  t 

TO 

02 

07 

Z5 

11 

TO 

02 

00 

YO 

05 

09 

20 

06 

22 

y 

400  if<to  1 

00 

00 

00 

YO 

Z3 

4l 

04 

i 

print,  'TOO  LARGE'  print -and-retum 

00 

00 

z4 

59 

wo 

58 

22 

0 

0 if=to  2 

00 

00 

00 

ZO 

ZO 

72 

06 

1: 

i print,  y print- and-retum 

00 

00 

YO 

59 

wo 

58 

21 

2: 

TO  UO  shift 

00 

00 

00 

TO 

UO 

99 

08 

i 

= i-1 

00 

wo 

03 

wo 

01 

Z1 

22 

0 

i if<to  0 

00 

00 

00 

ZO 

wo 

4o 

10 

stop 

00 

00 

00 

00 

zz 

08 
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Each  UNIVAC  word  consisted  of  twelve  6-bit  bytes,  and  the  Short 
Code  equations  were  "symbologically"  transliterated  into  groups  of  six 
2-byte  packets  using  the  following  equivalents  (among  others): 


01 

- 

06 

abs  value 

In 

(n+2)nd  power 

59 

print  and  return  carriage 

02 

( 

07 

+ 

2n 

(n+2)nd  root 

7n 

if=  to  n 

03 

= 

08 

pause 

bn 

if<to  n 

99 

cyclic  shift  of  memory 

Olt 

/ 

09 

) 

58 

print  and  tab 

Sn, 

Tn, ...,Zn  quantities 

Thus,  " i = 10  " would  actually  be  coded  as  the  word  " 00  00  00  WO  03  Z2  " 

as  shown;  packets  of  00  ' s could  be  used  at  the  left  to  fill  a word. 
Multiplication  was  indicated  simply  by  juxtaposition  (see  line  01). 

The  system  was  an  algebraic  interpreter,  namely  an  interpretive 
routine  which  continuously  scanned  the  coded  representation  and  performed 
the  appropriate  operations.  The  interpreter  processed  each  word  from 
right  to  left,  so  that  it  would  see  the  " ="  sign  last.  This  fact  needed 
to  be  understood  by  the  programmer,  who  had  to  break  long  equations  up 
appropriately  into  several  words  (cf.  lines  01  and  02);  see  also  the 
print  instructions  on  lines  04  and  06,  where  the  codes  run  from  right 
to  left. 

This  explanation  should  suffice  to  explain  the  TPK  program  above, 
except  for  the  "shift"  on  line  07 . Short  Code  had  no  provision  for 
subscripted  variables,  but  it  did  have  a 99  order  which  performed  a 
cyclic  shift  in  a specified  block  of  memory.  For  example,  line  0£  of 
the  above  program  means  " temp  = TO,  TO  = Tl,  . ..,  T9  = UO,  UO  = temp  "; 
and  fortunately  this  facility  is  all  that  the  TPK  algorithm  needs. 

The  following  press  release  from  Remington  Rand  appeared  in  Journal 
of  the  ACM,  1955,  page  291: 

Automatic  programming,  tried  and  tested  since  1950,  eliminates 
communication  with  the  computer  in  special  code  or  language.  ... 

The  Short-Order  Code  is  in  effect  an  engineering  "electronic 
dictionary"  ...  an  interpretive  routine  designed  for  the  solution 
of  one-shot  mathematical  and  engineering  problems. 
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[(Several  other  automatic  programming  systems,  including  "B-zero"  — which 
we  shall  discuss  later  — were  also  announced  at  that  time.)  This  is  one 
of  the  few  places  where  Short  Code  has  been  mentioned  in  the  open 
literature;  Grace  Hopper  referred  to  it  briefly  in  [HO  52,  p.  2k^>] 

(calling  it  "short-order  code"),  [HO  53>  p.  1^2]  ("short-code"), 

[HO  58,  p.  165]  ("Short  Code").  In  [HM  53>  p.  1252]  it  is  stated  that 
the  "short  code"  system  was  "only  a first  approximation  to  the  complete 
plan  as  originally  conceived."  This  is  probably  true,  but  several 
discrepancies  between  [HM  53]  and  [RR  55]  indicate  that  the  authors 
of  [HM  53]  were  not  fully  familiar  with  UNIVAC  Short  Code  as  it  actually 
existed. 

The  Intermediate  PL  of  Burks. 

Independent  efforts  to  simplify  the  job  of  coding  were  being  made 
at  this  time  by  Arthur  W.  Burks  and  his  colleagues  at  the  University  of 
Michigan.  The  overall  goal  of  their  activities  was  to  investigate  the 
process  of  going  from  the  vague  "Ordinary  Business  English”  description 
of  a data-processing  problem  to  the  "Internal  Program  Language"  description 
of  a machine-language  program  for  that  problem;  and,  in  particular,  to 
break  this  process  up  into  a sequence  of  smaller  steps. 

This  has  two  principal  advantages.  First,  smaller  steps  can 
more  easily  be  mechanized  than  larger  ones.  Second,  different 
kinds  of  work  can  be  allocated  to  different  stages  of  the 
process  and  to  different  specialists.  [BU  51>  p.  12] 

In  1950,  Burks  sketched  a so-called  "Intermediate  Programming  Language" 
which  was  to  be  the  step  one  notch  above  the  Internal  Program  Language. 
Instead  of  spelling  out  complete  rules  for  this  Intermediate  Programming 
Language,  he  took  portions  of  two  machine  programs  previously  published 
in  [BU  50]  and  showed  how  they  could  be  expressed  at  a higher  level  of 
abstraction.  From  these  two  examples  it  is  possible  to  make  a reasonable 
guess  at  how  he  might  have  written  the  TPK  algorithm  at  that  time: 

. 


I i 

L _ _ ___ 


1.  10  - i 

To  10. 

From  1,35 


10. 

A+i  - 11 

Compute  location 

of  a. 

l 

11. 

[A+i]  - t 

Look  up  and. 

transfer  to  storage 

12. 

|t  |1//2  + 5t5  - y 

y.  =V|a.|  + 5a^ 

13. 

To  20 
To  30 

1*00,  y;  20,30 
if  y > 1*00 
if  y < 1*00 

Determine  if 

= ^i 

From  13 

20. 

999  - y 

v.  = 999 

To  30 

From  13,: 

20 

30. 

(B  + 20  -2i)  ' - 31 

Compute  location 

°f  b20-2i 

31. 

i ->  [B  + 20  -2i] 

b20-2i  = 1 

32. 

(B  + 20  -2i)+l  33 

Compute  location 

of  b21-2i 

33- 

y - [(B  + 20  - 2i)+l] 

b21-2i  = Vi 

3b. 

i-1  -»  i 

i i+1 

35. 

To  1*0 
To  10 

i,  0;  1*0,10 
if  i < 0 
if  i > 0 

Repeat  cycle  until  i negative 

From  35 

1*0. 

F 

Stop  execution 
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Comments  at  the  right  of  this  program  attempt  to  indicate  Burks's 
style  of  writing  comments  at  that  time;  and  they  succeed  in  making  the 
program  almost  completely  self-explanatory.  Note  that  the  assignment 
operation  is  well  established  by  now;  and  Burks  used  it  also  in  the 
somewhat  unusual  form  " i -*  i+1  " shown  in  the  comment  to  instruction  34 
[BU  50,  p.  4l] . 

The  prime  symbol  which  appears  within  instruction  30  meant  that  the 
computer  was  to  save  this  intermediate  result,  as  it  was  a common 
subexpression  that  could  be  used  later  without  recomputation.  Burks 
mentioned  that  several  of  the  ideas  embodied  in  this  language  were  due 
to  Janet  Wahr,  Don  Warren,  and  Jesse  Wright. 

Methods  of  assigning  addresses  ari  of  expanding  abbreviated 
commands  into  sequences  of  commands  can  be  worked  out  in  advance. 
Hence  the  computer  could  be  instructed  to  do  this  work.  ...  It 
should  be  emphasized,  however,  that  even  if  it  were  not  efficient 
to  use  a computer  to  make  the  translation,  the  Intermediate  PL 
would  nevertheless  be  useful  to  the  human  programmer  in  planning 
and  constructing  programs.  [BU  51>  p.  13] 

At  the  other  end  of  the  spectrum,  nearer  to  Ordinary  Business 
Language,  Burks  and  his  colleagues  later  proposed  an  abstract  form  of 
description  which  may  be  of  independent  interest,  even  though  it  does 
not  relate  to  the  rest  of  our  story.  The  following  example  suffices 
to  give  the  flavor  of  their  "first  Abstraction  Language",  proposed  in 
1954: 
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On  the  first  line,  c denotes  the  customer's  name  and  address;  and  d 
is  " 1 inst  ",  the  first  of  the  current  month.  The  symbol  (x^, . . ., xn) 
was  used  to  denote  a list  of  all  n-tuples  (x^, ...,xn)  of  category  i , 
in  order  by  the  first  component  x^  ; and  the  meaning  of  the  second  line 
is  "a  listing,  in  order  of  date  d , of  all  invoices  and  all  remittances 
for  the  past  month".  Here  fk, s,u]  was  an  invoice,  characterized  by 
its  number  k , its  dollar  amount  s , and  its  discount  u ; [a, r]  was 
a remittance  of  r dollars,  identified  by  number  a ; and  " 1 ult  " means 
the  first  of  the  previous  month.  The  bottom  gives  the  customer’s  old 
balance  from  the  previous  statement,  and  the  new  balance  on  the  right. 

"The  notation  is  so  designed  as  to  leave  unprejudiced  the  iwthod  of  the 
statement's  preparation."  [BC  54]  Such  notations  have  not  won  over  the 
business  community,  however,  perhaps  for  the  reasons  explained  by 
Grace  Hopper  in  [HO  58,  p.  198]: 

I used  to  be  a mathematics  professor.  At  that  time  I found  there 
were  a certain  number  of  students  who  could  not  learn  mathematics. 

I then  was  charged  with  the  job  of  making  it  easy  for  businessmen 
to  use  our  computers.  I found  it  was  not  a question  of  whether 
they  could  learn  mathematics  or  not,  but  whether  they  would.  • . • 

They  said,  "Throw  those  symbols  out  — I do  not  know  what  they  mean, 

I have  not  time  to  learn  symbols."  I suggest  a reply  to  those 
who  would  like  data  processing  people  to  use  mathematical  symbols 
that  they  make  them  first  attempt  to  teach  those  symbols  to 
vice-presidents  or  a colonel  or  admiral.  I assure  you  that  I 
tried  it. 

Rutishauser ' s contribution. 

Now  let  us  shift  our  attention  once  again  to  Europe,  where  the  first 
published  report  on  methods  for  machine  code  generation  was  about  to 
appear.  Heinz  Rutishauser  was  working  with  the  Z4  computer  which,  by 
then,  had  been  rebuilt  and  moved  to  the  Swiss  Federal  Institute  of 
Technology  (E.T.H. ) in  Zurich;  and  plans  were  afoot  to  build  a brand  new 
machine  there.  The  background  of  Rutishauser' s contribution  can  best  be 
explained  by  quoting  from  a letter  he  wrote  some  years  later: 


ft 
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I am  proud  that  you  are  talcing  the  trouble  to  dig  into  my  1952 
pape  . On  the  other  hand  it  makes  me  sad,  because  it  reminds  me 
of  thv  remat u_e  death  of  an  activity  that  I had  started  hopefully 
in  15l*9>  but  could  not  continue  after  1951  because  I had  to  do 
other  work  — to  run  practically  singlehanded  a fortunately  slow 
computer  as  mathematical  analyst,  programmer,  operator  and  even 
troubleshooter  (but  not  as  an  engineer).  This  activity  forced 
me  also  to  develrn  new  numerical  methods,  simply  because  the  ones 
then  know..  !d  nou  vork  in  larger  problems.  Afterwards  when  I 
would  have  had  more  time,  I did  not  come  back  to  automatic 
programming  but  found  more  taste  in  numerical  analysis.  Only  much 
later  I was  invited  — more  for  historical  reasons,  as  a living 
fossil  so  to  speak,  than  for  actual  capacity  — to  join  the  ALGOL 
venture.  The  1952  paper  simply  reflects  the  stage  where  I had  to 
give  up  automatic  programming,  and  I was  even  glad  that  I was  able 
to  put  out  that  interim  report  (although  I knew  that  it  was  final). 
[RU  63] 

Rutishauser' s comprehensive  treatise  [RU  52]  described  a hypothetical 
computer  and  a simple  algebraic  language,  together  with  complete 
flowcharts  for  two  compilers  for  that  language.  One  compiler  expanded 
all  loops  out  completely,  while  the  other  produced  compact  code  using 
index  registers.  His  source  language  was  somewhat  restrictive,  since 
there  was  only  one  nonsequential  control  structure  (the  for  statement); 
but  that  control  structure  was  in  itself  an  important  contribution  to 
the  later  development  of  programming  languages.  Here  is  how  he  might 
have  written  the  TPK  algorithm: 

1 Fur  i = 10(-1)0 

2 a.  =£=  t 

£ (Sqrt  Abs  t)  + (5  xt  xt  xt)  =^=  y 
L Max(Sgn(y-UOO),  0)  =^=  h 

5 Z0.  ^ b20-2i 

6 (hx999)  + ((l-h)  xy)  b21_2. 

£ Ende  Index  i 

8 Schluss 
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Since  no  "if  ...  then"  construction  --much  less  go  to  --  was  present 
in  his  language,  the  computation  of 


y , if  y < ^00  , 
999  , if  y > LOO  , 


has  been  done  here  in  terms  of  the  Max  and  Sgn  functions  he  did  have, 
plus  appropriate  arithmetic;  see  lines  4 and  6.  (The  function  Sgn(x) 
is  0 if  x=0,or  +1  if  x>0,or  -1  if  x < 0 . ) Another 
problem  was  that  he  gave  no  easy  mechanism  for  converting  between 
indices  and  other  variables;  indices  (i.e.,  subscripts)  were  completely 
tied  to  Fur  - Ende  loops.  The  above  program  therefore  invokes  a 
trick  to  get  i into  the  main  formula  on  line  k;  " Z 0..  " is  intended 
to  use  the  Z instruction  which  transfered  an  indexed  address  to  the 
accumulator  in  Rutishauser' s machine  [RU  52,  p.  10],  and  it  is  possible 
to  write  this  in  such  a way  that  his  compiler  would  produce  the  correct 
code.  It  is  not  clear  whether  or  not  he  would  have  approved  of  this 
trick;  if  not,  we  could  have  introduced  another  variable,  maintaining 
its  value  equal  to  i . But  since  he  later  wrote  a paper  entitled 
"Interference  with  an  ALGOL  procedure,"  there  is  some  reason  to  ' elieve 
he  would  have  enjoyed  the  trick  very  much. 

As  with  Short  Code,  the  algebraic  source  code  symbols  had  to  be 
transliterated  before  the  program  was  amenable  to  computer  input,  and 
the  programmer  had  to  allocate  storage  locations  for  the  variables  and 
constants.  Here  is  how  our  TPK  program  would  have  been  converted  to  a 
sequence  of  (floating-point)  numbers  on  punched  paper  tape,  using  the 
memory  assignments  a^  = 100 + i , b^  = 200 + i , 0 = 500  , 1 = 5°1  > 

5 = 502  , LOO  = 505  , 999  = 50L  , y = 505  , h = 506  , t = 507  : 


f 


1 


Fur  i = 10  (-1)  0 

1012  , 50  , 10  , -1  , 0 , Q , 

begin  stmt  a sub  i =^=  t 

2 010000  , 100  , .001  , 200000  ,307,  Q , 

begin  stmt  ( t Abs  dummy  Sqrt 

010000  , 010000  , 307  , 110000  , 0 , 350800  , 

dummy  ) + ( 5 X t x 

0 , 2000000  , 020000  , 010000  , 302  , 060000  , 307  , 060000  , 


t X 

■t  ) 

=*= 

y 

307  , 060000 

y 

307  , 200000  , 

200000 

, 305  , 

Q , 

begin  stmt 

( ( 

y 

- 

400 

) 

Sgn 

010000  , 

010000  , 010000  , 

305  , 

030000  , 

303  , 

200000  , 

100000  , 

dummy  ) 

Max 

0 

=*= 

h 

0 , 200000 

, 080000  , 

300 

, 2000000  , 306 

, Q , 

begin  stmt 

Z 

0 

sub  i 

b20 

sub  -2i 

5 

010000  , 

0 

, 230000  , 

0 , 

.001  , 

200000 

, 220  , 

-.002 

> Q > 

begin  stmt 

( h 

X 

999 

) 

+ 

( 

6 

0100000  , 

010000  , 306 

, 060000  , 

304  , 200000  , 

020000  , 

010000  , 

( 1 

- 

h 

) 

X 

y 

) 

010000  , 301 

y 

030000  , 3 

06  , 

200000 

, 060000 

, 305 

, 200000 

, 200000 

bgl  sub  -2i 

221  , -.002  , Q , 

Ende 

1 Q > Q > 

Schluss 

Q , Q . 
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Here  Q represents  a special  flag  that  was  distinguishable  from 

all  numbers.  The  transliteration  is  straightforward,  except  that  unary- 

operators  such  as  " Abs  x"  have  to  be  converted  to  binary  operators 

"x  Abs  0 " . An  extra  left  parenthesis  is  inserted  before  each  formula, 

to  match  the  =£*=  (which  has  the  same  code  as  right  parenthesis). 

Subscripted  variables  whose  address  is  a + Zj  c.i.  are  specified  by 

^ " -3  j 

writing  the  base  address  a followed  by  a sequence  of  values  c.10  ; 

J 

this  scheme  allows  multiple  subscripts  to  be  treated  in  a simple  way. 

The  operator  codes  were  chosen  to  make  life  easy  for  the  compiler; 
for  example,  020000  was  the  machine  operation  "add"  as  well  as  the 
input  code  for  + , so  the  compiler  could  treat  almost  all  operations 
alike.  The  codes  for  left  and  right  parentheses  were  the  same  as  the 
machine  operations  to  load  and  store  the  accumulator,  respectively. 

Since  his  compilation  algorithm  is  published  and  reasonably  simple, 
we  can  exhibit  exactly  the  object  code  that  would  be  generated  from  the 
above  source  input.  The  output  is  fairly  long,  but  we  shall  consider 
it  in  its  entirety  in  view  of  its  importance  from  the  standpoint  of 
compiler  history.  Each  word  in  Rutishauser ' s machine  held  two  instructions, 
and  there  were  12  decimal  digits  per  instruction  word. 


Machine  instruction 


Symbolic  form 


230010 

200050 

10  -*  Op  , Op  -*  i , 

230001 

120000 

1 -*  Op  , -Op  - Op  , 

200051 

230000 

Op  -•  i'  , 0 -•  Op 

200052 

220009 

Op  - i"  , *+l  IR^ 

239001 

200081 

l+IR<j  -*  Op  , Op  -•  L-^ 

000000 

230100 

No-op  , loc  a — Op 

200099 

010050 

Op  -*  T , i - Op 

020099 

210001 

Op+T  -•  Op  , Op  ->  IR^ 

011000 

200307 

a^  -•  Op  , Op  -*  t 

010307 

110000 

t ->  Cp  , | Op  | — Op 

220009 

350800 

*+l  IR^  , go  to  Sqrt 

000000 

000000 

no-op,  no-op 

200999 

010302 

Op  - P1  , 5 - Cp 

I 


Machine  Instruction 

060307  060307 

060307  200998 
010999  020998 
200305  010305 

030303  200999 

010999  100000 
200998  010998 
080300  200306 
230000  200099 
010050  020099 
210001  230220 
200099  230002 
120000  060050 
020099  210002 
010000  231000 
202000  230221 
200099  230002 
120000  060050 
020099  210001 
010301  030306 
200999  010306 
060301+  200998 
010999  060305 
200997  010998 
020997  201000 
010081  210009 
010050  220008 
030052  388003 
010050  020051 
200050  359000 
000000  999999 
999999 


* 


Symbolic  form 

Op  xt  - Op  , Op  x t — Op 
Op  X t -•Op  , Qp  - P£ 

P-L  - Op  , 0pfP2  - Op 
Qp  - y , y - Op 
Op-l+OO  - Op  , Op  - p^ 

P^  — Op  , Sgn  Op  - Op 

Op  - P2  ’ p2  "*  °P 

Max(0p,0)  - Op  , Op  - h , 

0 — Op  , Op  — T 

1 - Qp  , OpfT  — Op 

Op  - IR-l  , loc  b2Q  - Op 
Op  - T , 2 - Op 
-Op  - Op  , Op  xi  — Qp 
Op+T  - Qp  , Op-IH, 

a 

(0)  - Op  , IR±  - Op 

PP  - h20-Si  ’ l0C  b21  -*  05 
Qp  - T , 2 - Op 

-Op  - Op,  Opxi-Op 
OpH-T  - Op  , Op  - IR.^ 

1 — Op  , Op-h  - Op 

Op  - , h - Op 

Op  x 999  - Qp  ) Qp  - P2 

P1-Op,  Opxy-Qp 

Qp  - P^  , P2  - Qp 

Qp*- p5  - Qp  , Qp  - b21.2i 

\ - Op  , Op  - ir9 

i - Qp  , *+l  - IRg 

Qp-i"  - Op  , to  (IRq+3)  if  Op  = 0 

i - Qp  , Optf-i'  - Op 

Qp  - i , to  (IR^) 

no-op  , stop 

stop 
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(Several  bugs  on  pp.  39-^0  of  [RU  52]  needed  to  be  corrected  in  order 
to  produce  this  code,  but  Rutishauser' s original  intent  was  reasonably 
clear.  The  most  common  error  made  by  a person  who  first  tries  to  write 
a compiler  is  to  confuse  compilation  time  with  object-code  time,  and 
Rutishauser  gets  the  honor  of  being  first  to  make  this  error! ) 

The  above  code  has  the  interesting  property  that  it  is  completely 
relocatable  — even  if  we  move  all  instructions  up  or  down  by  one-half 
a word.  Careful  study  of  the  output  shows  that  index  registers  were 
treated  rather  awkwardly;  but  after  all,  this  was  1951,  and  many 
compilers  even  nowadays  produce  far  more  disgraceful  code  than  this. 

Rutishauser  published  slight  extensions  of  his  source  language 
notation  in  [RU  55]  and  [RU  55']. 


Bohm' s Compiler. 

An  Italian  graduate  student,  Corrado  Bohm,  developed  a compiler  at 
the  same  time  and  in  the  same  place  as  Rutishauser,  so  it  is  natural  to 
assume  — as  many  people  have  --  that  they  worked  together.  But  in  fact, 
their  methods  had  essentially  nothing  in  common.  Bohm  (who  was  a student 
of  Eduard  Stiefel)  developed  a language,  a machine,  and  a translation 
method  of  his  own,  during  the  latter  pant  of  1950,  knowing  only  of 
[GV  U7]  and  [ZU  k8];  he  learned  of  Rutishauser ’ s similar  interests  only 
after  he  had  submitted  his  doctoral  dissertation  in  1951>  and  he  amended 
the  dissertation  at  that  time  in  order  to  clarify  the  differences  between 
their  approaches. 


Bohm's  dissertation  [BO  52]  was  especially  remarkable  because  he 
not  only  described  a complete  compiler,  he  also  defined  that  compiler 
in  its  own  language'.  And  the  language  was  interesting  in  itself, 
because  every  statement  (including  input  statements,  output  statements, 
and  control  statements)  was  a special  case  of  an  assignment  statement. 
Here  is  how  TPK  looks  in  Bohm's  language: 


A.  Set  i = 0 (plus  the 
base  address  100  for 
the  input  array  a ) . 


Jt'  - A 
100  - i 
B -•  Jt 


B.  Let  a new  input  a^  be  jt' 

given.  Increase  i by  unity,  ? 

and  proceed  to  C if  i > 10  , i+1 

otherwise  repeat  B . [ (l  fl  (i-110) )» C]+[  (1-  (i-1]  0) ) »B] 


B 

ii 

i 

jt 


C.  Set  i = 10  . 


it*  - C 
110  - i 


D.  Call  x the  number  a„.  , 
and  prepare  to  calculate 
its  square  root  r (using 
subroutine  R ),  returning 
to  E . 


it'  D 
ii  - x 
E — X 
R - Jt 


E.  Calculate  f(a^)  and 
attribute  it  to  y . 

If  y > 400,  continue 
at  F,  otherwise  at  G. 


it'  E 
rt-5  • ii  • ii  • ii  - y 
[(1  H (y-400))-F]+[(l-(y-400))-G]  - it 


F.  Output  the  actual  value 
of  i , then  the  value 
999  ("too  large”). 
Proceed  to  H. 


it’  - F 
i-100  - ? 
999  - ? 
H - it 
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A 


T~ 


» 


h 


t 


» 


* 


» 
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G.  Output  the  actual 

values  of  i and  y . 


it'  - G 

1-100  - ? 

y - ? 

H - it 


H.  Decrease  i by  unity, 
and  return  to  D if 
i > 0 . Otherwise  stop. 


it'  - H 


i-1  - i 

[(l-(lOO-i))-D]+[(in  (l00-i))-03  - It 


Here  comments  in  an  approximation  to  Bohm' s style  appear  on  the  left, 
while  the  program  itself  is  on  the  right.  As  remarked  earlier,  every- 
thing in  Bohm's  language  appears  as  an  assignment.  The  statement 
" B - it  " means  " go  to  B ",  i.e.,  set  the  program  counter  it  to  the 
value  of  variable  B . The  statement  " it'  — B " means  "this  is  label  B"; 
a loading  routine  preprocesses  the  object  code,  using  this  type  of 
statement  to  set  the  initial  value  of  variable  B rather  than  to  store 
an  instruction  in  memory.  The  symbol  " ? " stands  for  the  external 
world,  hence  the  statement  " ? -*  x " means  "input  a value  and  assign 
it  to  x";  the  statement  " x -•  ? " means  "output  the  current  value  of  x". 
An  arrow  " l " is  used  to  indicate  indirect  addressing  (restricted  to 
one  level);  thus,  " ? -♦  Ji  " in  part  B means  "read  one  input  into  the 
location  whose  value  is  i ",  namely  into  a^  . 

Bohm' s machine  operated  only  on  nonnegative  integers  of  it  decimal 
digits.  As  a consequence,  his  operation  x-y  was  the  logician's 
subtraction  operator, 


if  x > y ; 
if  x < y . 


He  also  used  the  notation  xfly  for  min(x,y)  . Thus  it  can  be  verified 


that 


in(i-j) 


if  i > j ; 
if  i < j ; 


» 
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, if  i > j ; 

, if  i < j . 

Because  of  these  identities,  the  complicated  formula  at  the  end  of  part  B 
is  equivalent  to  a conditional  branch, 

C -*  n , if  i > 110  ; 

B -»  it  , if  i < HQ  . 


l-(i-j)  = 


It  is  easy  to  read  Bohm's  program  with  these  notational  conventions 
in  mind.  Note  that  part  C doesn't  end  with  ” D -*  « ",  although  it  could 
have;  similarly  we  could  have  deleted  " B - n " after  part  A.  (Bohm 
omitted  a redundant  go-to  statement  only  once,  out  of  six  chances  he 
had  in  [BO  52] . ) 

Part  D shows  how  subroutines  are  readily  handled  in  his  language, 
although  he  did  not  explicitly  mention  them.  The  integer  square  root 
subroutine  can  be  programmed  as  follows,  given  the  input  x and  the 
exit  location  X : 

46 

R.  Set  r = 0 and  t = 2 it ’ -*  R 

0 - r 

7036874417766!  - t 
S ->  n 


S.  If  r*t  < x , go  to  T , 
otherwise  go  to  U . 


n'  - S 
r+t  lx  -«  u 
[(l-u)-T]+[(l  flu).U]  - it 


T.  Decrease  x by  r*t  , 

divide  r by  2 , increase 
r by  t , and  go  to  V . 


it’  - T 
x-r-t  -*  x 
r:2+t  - r 
V - it 


U.  Divide  r by  2 . it'  ->  U 

r:2  - r 
V - it 
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V.  Divide  t by  1)  . If  t = 0 , n'  — U 

exit,  othervri.se  return  to  S . t:4  — t 

[ (i*t) -x]+t (i  nt)-s]  - * 

(This  algorithm  is  equivalent  to  the  classical  pencil- and-paper  method 
for  square  roots,  adapted  to  binary  notation.  It  was  given  in  hardware- 
oriented  form  as  example  P9.18  by  Zuse  in  [ZU  45,  pp.  143-159].  To  prove 
its  validity,  one  can  verify  that  the  following  invariant  relations  hold 
when  we  reach  step  S: 

t is  a power  of  4 ; 
r is  a multiple  of  4t  ; 
r^/4t  + x = initial  value  of  x ; 

0 < x < 2r+4t  . 

At  the  conclusion  of  the  algorithm  these  conditions  hold  with  t = 1/4  ; 
so  r is  the  integer  square  root  and  x is  the  remainder.) 

Bohm' s one-pass  compiler  was  capable  of  generating  instructions 
rapidly,  as  the  input  was  being  read  from  paper  tape.  Unlike  Rutishauser, 
Bohm  recognized  operator  precedence  in  his  language;  for  example,  r:2+t 
was  interpreted  as  (r:2)+t  , the  division  operator  " : " taking 
precedence  over  addition.  However,  Bohm  did  not  allow  parentheses  to  be 
mixed  with  precedence  relations:  If  an  expression  began  with  a left 

parenthesis,  the  expression  had  to  be  fully  parenthesized  even  when 
associative  operators  were  present;  on  the  other  hand  if  an  expression 
did  not  begin  with  a left  parenthesis,  precedence  was  considered  but  no 
parentheses  were  allowed  within  it.  The  complete  program  for  his 
compiler  consisted  of  114  assignments,  broken  down  as  follows: 

(i)  59  statements  to  handle  formulas  with  parentheses 

(ii)  51  statements  to  handle  formulas  with  operator  precedence 

(iii)  4 statements  to  decide  between  (i)  and  (ii). 

There  was  also  a loading  routine,  described  by  lb  assignment  statements; 
so  the  compiler  amounted  to  only  130  statements  in  all,  including  33 
statements  which  were  merely  labels  («'  -*...)  . This  brevity  is 
especially  surprising  when  we  realize  that  a good  deal  of  the  program 


< 


:1 


39 


was  devoted  solely  to  checking  the  input  for  correct  syntax;  this  check 
was  not  complete,  however.  [It  appears  to  be  necessary  to  add  one  more 
statement  in  order  to  fix  a bug  in  his  program,  caused  by  overlaying 
information  when  a left  parenthesis  follows  an  operator  symbol;  but  even 
witn  this  "patch"  the  compiler  is  quite  elegant.] 

2 

Rutishauser' s parsing  technique  often  required  order  n steps  to 
process  a formula  of  length  n . His  idea,  which  we  have  seen  illustrated 
above,  was  to  find  the  leftmost  pair  of  parentheses  which  have  the  highest 
level,  so  that  they  enclose  a parenthesis-free  formula  a , and  to  compile 
the  code  for  " a - P ";  then  the  subformula  " (a)  " was  simply  replaced 
by  " ",  q was  increased  by  1 , and  the  process  was  iterated  until 

no  parentheses  remained.  Bohm's  parsing  technique,  on  the  other  hand, 
was  of  order  n , generating  instructions  in  what  amounts  to  a linked 
binary  tree  while  the  formula  was  being  read  in;  to  some  extent,  his 
algorithm  anticipated  modem  list-processing  techniques,  which  were  first 
made  explicit  by  Newell,  Shaw,  and  Simon  about  1956  (cf.  [KN  68,  p.  i+57 ] ) - 
Here  is  a brief  indication  of  how  Bohm's  algorithm  would  have  translated 
the  statement  ( (a:  (b -c) )+( (d  fl  e)-f ) ) -♦  g , assuming  that  the  bug  referred 
to  above  had  been  removed: 
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Current  Current  Contents  of  tree  (instructions  and  stack  pointers) 
partial  position  __  __  __ 

Input  instruction  in  tree  (2)  © © © 
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dn 
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0+0,0 
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© 

0+0-0 

a:©  - 0 

b -c  -© 

©-f-©| 

dHe  w© 

- 

© 

© 

©+©-© 

a:©  -0 

b-c  -© 

© -f  -0! 

dOe-© 

At  this  point  the  contents  of  the  tree  would  be  punched  out,  in  reverse 

preorder: 

dfle  - 0 

©^  - © 
b>c  — © 
a:©  - © 

0+@  - © 

and  the  following  symbol  " g " would  evoke  the  final  instruction  " - g " . 
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Bohm's  compiler  assumed.' that  the  source  code  input  would  be  " raj-  - 
literated  into  numeric  form,  hut  in  an  Italian  patent  filed  in  1952  hr 
proposed  that  it  should  actually  be  punched  on  tape  using  a typewriter 
with  the  following  keyboard  [BO  52',  Fig.  9l : 

000060© ©©© 
@©@©©©©©©©0 
@©®®©®©©©© 
©®®©0@©©© 


Constants  in  the  source  program  were  to  be  assigned  a variable  name  and 
input  separately. 

Of  a.l  1 the  authors  we  shall  consider,  Bohm  was  the  only  one  who  gave 
an  argument  that  his  language  was  universal,  i.e.,  capable  of  computing 
any  computable  function. 

Meanwhile,  in  England. 

Our  story  so  far  has  introduced  us  to  many  firsts,  such  as  the  first 
algebraic  interpreter,  the  first  algorithms  for  parsing  and  code  generation, 
the  first  compiler  in  its  own  language.  Now  we  come  to  the  first  real 
compiler,  in  the  sense  that  it  was  really  implemented  and  used;  it  really 
took  algebraic  statements  and  translated  them  into  machine  language. 

The  unsung  hero  of  this  development  was  Alick  E.  Glennie  of  Fort  Halstead, 
the  Royal  Armaments  Research  Establishment.  We  may  justly  say  "unsung" 
because  it  is  very  difficult  to  deduce  from  the  published  literature  that 
Glennie  introduced  this  system.  When  Christopher  Strachey  referred  favorably 
to  it  in  [ST  52,  pp.  46-1+7],  he  did  not  mention  Glennie's  name,  and  it  was 
inappropriate  for  Glennie  to  single  out  his  own  contributions  when  he  co-authored 
an  article  with  J.  M.  Bennett  at  the  time  [BG  53>  PP*  112-113 ] ♦ In  fact, 
there  are  apparently  only  two  published  references  to  Glennie's  authorship 
of  this  early  compiler;  one  of  these  was  a somewhat  cryptic  remark  inserted 
by  an  anonymous  referee  into  a review  of  Bohm's  paper  [TA  56]  while  the 
other  appeared  in  a comparatively  inaccessible  publication  [MG  53]* 
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Glennie  called  his  system  AUTOCODE;  and  it  may  well  have  helped  to  inspire 
many  other  "Autocode"  routines,  of  increasing  sophistication,  developed 
during  the  late  1950's.  Strachey  said  that  AUTOCODE  was  beginning  to 
come  into  use  in  September,  1952.  The  Manchester  Mark  I machine  language 
was  particularly  abstruse  — see  [WO  51]  for  an  introduction  to  its 
complexities,  including  the  intricacies  of  Teleprinter  code  (used  for 
base-32  arithmetic,  backwards)  --  and  its  opaqueness  may  have  been  why 
this  particular  computer  witnessed  the  world's  first  compiler.  Glennie 
stated  his  motivations  this  way,  at  the  beginning  of  a lecture  he 
delivered  at  Cambridge  University  in  February,  1953 : 

The  difficulty  of  programming  has  become  the  main  difficulty 
in  the  use  of  machines.  Aiken  has  expressed  the  opinion  that  the 
solution  of  this  difficulty  may  be  sought  by  building  a coding 
machine,  and  indeed  he  has  constructed  one.  However  it  has  been 
remarked  that  there  is  no  need  to  build  a special  machine  for 
coding,  since  the  computer  itself,  being  general  purpose,  should 
be  used.  ...  To  make  it  easy,  one  must  make  coding  comprehensible . 

This  may  be  done  only  by  improving  the  notation  of  programming. 

Present  notations  have  many  disadvantages:  all  are  incomprehensible 

to  the  novice,  they  are  all  different  (one  for  each  machine)  and 
they  are  never  easy  to  read.  It  is  quite  difficult  to  decipher 
coded  programmes  even  with  notes,  and  even  if  you  yourself  made 
the  programme  several  months  ago. 

Assuming  that  the  diff iculties  may  be  overcome,  it  is  obvious 
that  the  best  notation  for  programmes  is  the  usual  mathematical 
notation,  because  it  is  already  known.  ... 

Using  a familiar  notation  for  programming  has  very  great 
advantages,  in  the  elimination  of  errors  in  programmes,  and  the 
simplicity  it  brings.  [GL  52] 

His  reference  to  Aiken  should  be  clarified  here,  especially  because 
Glennie  stated  several  years  later  [GL  65]  that  "I  got  the  concept  from 
a reported  idea  of  Professor  Aiken  of  Harvard,  who  proposed  that  a 
machine  be  built  to  make  code  for  the  Harvard  relay  machines."  Aiken's 
coding  machine  for  the  Harvard  Mark  III  was  cited  also  by  Bohm 


[BO  52,  p.  176];  it  is  described  in  [HA  52,  pp.  56-58,  229-265,  illustrated 
on  pp.  20,  57>  250].  By  pushing  appropriate  buttons  on  the  console  of 
this  machine,  one  or  more  appropriate  machine  codes  would  be  punched 
on  tape  for  the  equivalent  of  three-address  instructions  such  as 
" -b5  x | ci [ - ai  " or  " l//x9  -•  rO  there  was  a column  of  keys  for 
selecting  the  first  operand's  sign,  its  letter  name,  and  its  (single) 
subscript  digit,  then  another  column  of  keys  for  selecting  the  function 
name,  etc.  (incidentally,  Heinz  Rutishauser  is  listed  as  one  of  the 
fifty-six  authors  of  the  Harvard  report  [HA  52];  his  visit  to  America 
in  1950  is  one  of  the  reasons  he  and  Bohm  did  not  get  together.) 

Our  TPK  algorithm  can  be  expressed  in  Glennie's  AUTOCODE  as  follows: 
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c@VA  t@IC  x@gC  y&RC  z@NC 
INTEGERS  +5  -c 
-t 

+t  TESTA  Z 

-t 

ENTRY  Z 

SUBROUTINE  6 - z 
+tt  ->y  — x 
+tx  -y  — * x 

+z+cx  CLOSE  WRITE  1 


11  a&/$  b@MA  c@GA  d@0A  e@PA  f@HA  i@VE  x@ME 

12  INTEGERS  +20  -b  +10  -c  +l«X>  -d  +999  -e  +1  -f 

12  LOOP  lOn 

lb  n — x 

15  +b-x  -* x 

16  x -«q 

12  SUBROUTINE  5 -aq 
18  REPEAT  n 
12  +c  -i 

20  LOOP  lOn 

21  +an  SUBROUTINE  1 -y 

22  +d-y  TESTA  Z 
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23 

+i  SUBROUTINE  3 

24 

+e  SUBROUTINE  4 

25 

CONTROL  X 

26 

ENTRY  Z 

21 

+i  SUBROUTINE  3 

28 

+y  SUBROUTINE  4 

22 

ENTRY  X 

22 

+ i-f  -»i 

2i 

REPEAT  n 

22 

ENTRY  A CONTROL  A WRITE  2 START  2 

Although  this  language  was  much  simpler  than  the  Mark  I machine  code, 
it  was  still  very  machine-oriented,  as  we  shall  see.  (Rutishauser  and 
Bohm  had  had  a considerable  advantage  over  Glennie  in  that  they  had 
designed  their  own  machine  code!)  Lines  1-10  of  this  program  represent 
a subroutine  for  calculating  f(t)  ; " CLOSE  WRITE  1 " on  line  10  says 
that  the  preceding  lines  constitute  subroutine  number  1.  The  remaining 
lines  yield  the  main  program;  " WRITE  2 START  2 " on  line  52  says  that 
the  preceding  lines  constitute  subroutine  number  2,  and  that  execution 
starts  with  number  2 . 

Let's  begin  at  the  beginning  of  this  program  and  try  to  give  a 
play-by-play  account  of  what  it  means.  Line  1 is  a storage  assignment 
for  variables  c , t , x , y , and  z , in  terms  of  absolute  machine 
locations  represented  in  the  beloved  Teleprinter  code.  Line  2 assigns 
the  value  5 to  c ; like  all  early  compiler-writers,  Glennie  shied 
away  from  including  constants  in  formulas.  Actually  his  language  has 
been  extended  here:  he  had  only  the  statement  "FRACTIONS"  for  producing 
constants  between  - £ and  ^ , assuming  that  a certain  radix  point 
convention  was  being  used  on  the  Manchester  machine.  Since  scaling 
operations  were  so  complicated  on  that  computer,  it  would  be  inappropriate 
for  our  purposes  to  let  such  considerations  mess  up  or  distort  the 
TPK  algorithm;  thus  the  INTEGERS  statement  (which  is  quite  in  keeping 
with  the  spirit  of  his  language)  has  been  introduced  to  simplify  our 
exposition. 
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Upon  entry  to  subroutine  1,  the  subroutine's  argument  was  in  the 
machine's  lower  accumulator;  line  5 assigns  it  to  variable  t . Line  1 
means  " go  to  label  Z if  t is  positive  line  5.  puts  -t  in  the 
accumulator;  and  line  6 defines  label  Z'.  Thus  the  net  effect  of  lines 
i thru  6 is  to  put  |t|  into  the  lower  accumulator.  Line  applies 
subroutine  6 (integer  square  root)  to  this  value,  and  stores  it  in  z . 

On  line  8 we  compute  the  product  of  t by  itself;  this  fills  both 
upper  and  lower  accumulators,  and  the  upper  half  (assumed  zero)  is 
stored  in  y , the  lower  half  in  x . Line  9 is  similar,  now  x 
contains  . Finally  line  10  completes  the  calculation  of  f(t) 
by  leaving  z+5x  in  the  accumulator.  The  "CLOSE"  operator  causes  the 
compiler  to  forget  the  meaning  of  label  Z , but  the  machine  addresses 
of  variables  c , x , y , and  z remain  in  force. 

Line  11  introduces  new  storage  assignments,  and  in  particular  it 
reassigns  the  addresses  of  c and  x . New  constant  values  are  defined 
on  line  12.  Lines  1^_  thru  18  constitute  the  input  loop,  enclosed  by 
LOOP  lOn  . . . REPEAT  n ; here  n denotes  one  of  the  index  registers 
(the  famous  Manchester  B-lines),  the  letters  k , 1 , n , o , q , r 
being  reserved  for  this  purpose,  I,oops  in  Glennie's  language  were 
always  done  for  decreasing  values  of  the  index,  up  to  and  including  0 ; 
and  in  our  case  the  loop  was  performed  for  n = 20, 18, 16, ...,2, 0 . 

These  values  are  twice  what  might  be  expected,  because  the  Mark  I 
addresses  were  for  half-words.  Lines  li  thru  16  set  index  q equal 
to  20-n  ; this  needs  to  be  done  in  stages  (first  moving  from  n to 
a normal  variable,  then  doing  the  arithmetic,  and  finally  moving  the 
result  to  the  index  variable) . The  compiler  recognized  conversions 
between  index  variables  and  normal  variables  by  insisting  that  all 
other  algebraic  statements  begin  with  a + or  - sign.  Line  !£_  says 
to  store  the  result  of  subroutine  5 (an  integer  input  subroutine)  into 
variable  af,  . 

Lines  20  thru  £1  comprise  the  output  loop.  Again  n has  the  value  2i  , 
so  the  true  value  of  i has  been  maintained  in  parallel  with  n (see 
lines  12  and  30) • Line  21  applies  subroutine  1 (namely  our  subroutine 
for  calculating  f(t)  ) to  a^  and  stores  the  result  in  y . Line  22 
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branches  to  label  Z if  hOO  > y ; line  25_  is  an  unconditional  jump 
to  label  X . Line  2J_  outputs  the  integer  i . using  subroutine  and 
subroutine  k in  line  2k  is  assumed  to  be  similar  except  that  a carriage- 
return  and  line-feed  are  also  output.  Thus  the  output  is  correctly 
performed  by  lines  22  thru  2£. 

The  operations  " ENTRY  A CONTROL  A " on  line  32.  define  an  infinite 
loop  " A:  go  to  A " ; this  was  the  so-called  dynamic  stop  used  to 
terminate  a computation  in  those  good  old  days. 

Our  analysis  of  the  sample  program  is  now  complete.  Glennie's 
language  was  an  important  step  forward,  but  of  course  it  still  remained 
very  close  to  the  machine  itself.  And  it  was  intended  for  the  use  of 
experienced  programmers.  As  he  said  at  the  beginning  of  the  user's 
manual  [GL  52' ]>  "The  left  hand  side  of  the  equation  represents  the 
passage  of  information  to  the  accumulator  through  the  adder,  subtractor, 
or  multiplier,  while  the  right  hand  side  represents  a transfer  of  the 
accumulated  result  to  the  store."  The  existence  of  two  accumulators 
complicated  matters;  for  example,  after  the  multiplication  in  lines  £ 
and  9 the  upper  accumulator  was  considered  relevant  (in  the  ->  y ),  while 
elsewhere  only  the  lower  accumulator  was  used.  The  expression  " +a+bc  " 
meant  "load  the  lower  accumulator  with  a , then  add  it  to  the  double 
length  product  be  ",  while  " +bct-a  " meant  "form  the  double  length 
product  be  , then  add  a into  the  upper  half  of  the  accumulator" . 
Expressions  like  + ab + cd + ef  were  allowed,  but  not  products  of  three 
or  more  quantities;  and  there  was  no  provision  for  parentheses.  The 
language  was  designed  to  be  used  with  the  32-character  Teleprinter  code, 
where  -•  was  substituted  for  " . 

We  have  remarked  that  Glennie's  papers  have  never  been  published; 
this  may  be  due  to  the  fact  that  his  employers  in  the  British  atomic 
weapons  project  were  in  the  habit  of  keeping  documents  classified. 
Glennie's  work  was,  however,  full  of  choice  quotes,  so  it  is  interesting 
to  repeat  several  more  remarks  he  made  at  the  time; 


There  are  certain  other  rules  for  punching  that  are  merely  a 
matter  of  common  sense,  such  as  not  leaving  spaces  in  the  middle 
of  words  or  misspelling  them.  I have  arranged  that  such  accidents 
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This  consists  of  the  programme  coming  to  a stop  and  the  machine 
making  no  further  moves. 

[The  programme]  is  quite  long  but  not  excessively  long,  about 
750  orders.  ...  The  part  that  deals  with  the  translation  of  the 
algebraic  notation  is  the  most  intricate  programme  that  I have  ever 
devised  ...  [but  the  number  of  orders  required]  is  a small 
fraction  of  the  total,  about  lbO. 

My  experience  of  the  use  of  this  method  of  programming  has 
been  rather  limited  so  far,  but  I have  been  much  impressed  by 
the  speed  at  which  it  is  possible  to  make  up  programmes  and  the 
certainty  of  gaining  correct  programmes.  ...  The  most  important 
feature,  I think,  is  the  ease  with  which  it  is  possible  to  read 
back  and  mentally  check  the  programme.  And  of  course  on  such 
features  as  these  will  the  usefulness  of  this  type  of  programming 
be  judged.  [GL  52] 

At  the  beginning  of  the  user's  manual  [GL  52'],  he  mentioned  that 
"the  loss  of  efficiency  (in  the  sense  of  the  additional  space  taken  by 
routines  made  with  AUTOCODE)  is  no  more  thar  about  10$. " This  remark 
appeared  also  in  [BG  55>  p.  115 ]>  2nd  it  may  well  be  the  source  of  the 
oft-heard  opinion  that  compilers  are  "90$  efficient". 

On  the  other  hand,  Glennie's  compiler  actually  had  very  little 
tangible  impact  on  other  users  of  the  Manchester  machine.  For  this  reason, 
Brooker  did  not  even  mention  it  in  his  1958  paper  entitled  "The  Autocode 
Programs  developed  for  the  Manchester  University  Computers"  [BR  58], 

This  lack  of  influence  may  be  due  in  part  to  the  fact  that  Glennie  was 
not  resident  at  Manchester,  but  the  primary  reason  was  probably  that  his 
system  did  little  to  solve  the  really  severe  problems  that  programmers 
had  to  face,  in  those  days  of  small  and  unreliable  machines.  An 
improvement  in  the  coding  process  was  not  regarded  then  as  a breakthrough 
of  any  importance,  since  coding  was  often  the  simplest  part  of  a programmer’s 
task.  When  one  had  to  wrestle  with  problems  of  numerical  analysis,  scaling, 
and  two-level  storage,  meanwhile  adapting  one ' s program  to  the  machine ' s 
current  state  of  malfunction,  coding  itself  was  quite  insignificant. 
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Thus  when  Glennie  mentioned,  his  system  in  the  discussion  following 
[MG  53 ],  it  met  with  a very  cool  reception.  For  example,  Stanley  Gill's 
comment  reflected  the  prevailing  mood: 

It  seems  advisable  to  concentrate  less  on  the  ability  to  write, 
say 

+ a+  b+ab  ->  c 

as  it  is  relatively  easy  for  the  programmer  to  write 
A a 
A b 
H a 
V b 

T c . [MG  53,  p.  79] 

Nowadays  we  would  say  that  Gill  had  missed  a vital  point,  but  in  1953 
his  remark  was  perfectly  true. 

Some  13  years  later,  Glennie  had  the  following  reflections  [GL  65]: 

[The  compiler]  was  a successful  but  premature  experiment. 

Two  things  I believe  were  wrong:  (a)  Floating-point  hardware 

had  not  appeared.  This  meant  that  most  of  a programmer's  effort 
was  in  scaling  his  calculation,  not  in  coding,  (b)  The  climate 
of  thought  was  not  right.  Machines  were  too  slow  and  too  small. 

It  was  a programmer's  delight  to  squeeze  problems  into  the 
smallest  space.  ... 

I recall  that  automatic  coding  as  a concept  was  not  a novel 
concept  in  the  early  fifties.  Most  knowledgeable  programmers 
knew  of  it,  I think.  It  was  a well  known  possibility,  like  the 
possibility  of  computers  playing  chess  or  checkers.  ...  [Writing 
the  compiler]  was  a hobby  that  I undertook  in  addition  to  my 
employers'  business:  they  learned  about  it  afterwards.  The 

compiler  . . . took  about  three  months  of  spare  time  activity  to 
complete. 
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Early  American  "Compilers". 


None  of  the  authors  we  have  mentioned  so  far  actually  used  the  word 
"compiler"  in  connection  with  what  they  were  doing;  the  terms  were 
automatic  coding,  codification  automatique,  Rechenplanfertigung.  In  fact 
it  is  not  especially  obvious  to  programmers  today  why  a compiler  should  be 
so  called.  We  can  understand  this  best  by  considering  briefly  the  other 
types  of  programming  aids  that  were  in  use  during  those  early  days. 

The  first  important  programming  tools  to  be  developed  were,  of  course, 
general-purpose  subroutines  for  such  commonly  needed  processes  as 
input-output  conversions,  floating-point  arithmetic,  and  transcendental 
functions.  Once  a library  of  such  subroutines  had  been  constructed,  there 
was  time  to  think  of  further  ways  to  simplify  programming,  and  two 
principal  ideas  emerged:  (a)  Coding  in  machine  language  could  be  made 

less  rigid,  by'using  blocks  of  relocatable  addresses  [WH  50] . This  idea 
was  extended  by  M.  V.  Wilkes  to  the  notion  of  an  "assembly  routine",  able 
to  combine  a number  of  subroutines  and  to  allocate  storage  [WW  51,  pp.  27-32] 
and  Wilkes  later  [WI  52,  WI  53]  extended  the  concept  further  to  include 
general  symbolic  addresses  (i.e.,  not  simply  relative  to  a small  number  of 
origins).  For  many  years  these  were  called  "floating  addresses".  Similar 
developments  in  assembly  systems  occurred  in  America  and  elsewhere; 
cf.  [RO  52].  (b)  An  artificial  machine  language  or  pseudo-code  was 

devised,  usually  providing  easy  facilities  for  floating-point  arithmetic 
as  if  it  had  been  built  into  the  hardware.  An  "interpretive  routine" 
(sometimes  called  "interpretative"  in  those  days)  would  process  these 
instructions,  emulating  the  hypothetical  computer.  The  first  interpretive 
routines  appeared  in  programming's  first  textbook,  by  Wilkes,  Wheeler, 
and  Gill  [WW  51,  pp.  51*~57>  71+-77,  162-161+];  the  primary  aim  of  this  book 
was  to  present  a library  of  subroutines  and  the  methodology  of  their  use. 
Shortly  afterwards  a refined  interpretive  routine  for  floating-point 
calculation  was  described  by  Brooker  and  Wheeler  [BW  53 ],  including  the 
ability  for  subroutines  nested  to  any  depth.  Interpretive  routines  in 
their  more  familiar  comract  form  were  introduced  by  J.  M.  Bennett  (cf. 

[WW  51,  Preface  and  pp.  162-161+],  [gp  52]);  the  most  influential  was 
perhaps  John  Backus’s  IBM  701  Speedcoding  System  [BA  5*  , BH  51*].  As  we 
have  already  remarked,  Short  Code  was  a different  sort  of  interpretive 


routine.  The  early  history  of  library  subroutines,  assembly  routines, 
and  interpretive  routines  remains  to  be  written;  we  have  just  reviewed 
it  briefly  here  in  order  to  put  the  programming  language  developments 
into  context. 

During  the  latter  part  of  1951,  Grace  Murray  Hopper  developed  the 
idea  that  pseudo-codes  need  not  be  interpreted,  they  could  also  be 
expanded  out  into  direct  machine  language  instruction:  . and  her 

associates  at  UNIVAC  proceeded  to  construct  an  experimental  program 
which  would  do  such  a translation,  and  they  called  it  a compiling  routin':. 

To  compile  means  to  compose  out  of  materials  from  other  documents. 
Therefore,  the  compiler  method  of  automatic  programming  consists 
of  assembling  and  organizing  a program  from  programs  or  routines 
or  in  general  from  sequences  of  computer  code  which  have  been 
made  up  previously.  [MO  5*0  p.  15] 

(See  also  [HO  55,  p.  22].)  The  first  "compiler"  in  this  sense,  named  A-0, 
was  in  operation  in  the  spring  of  1952,  when  Dr.  Hopper  spoke  on  the 
subject  at  the  first  ACM  National  Conference  [HO  52].  Incidentally, 

M.  V.  Wilkes  came  up  with  a very  similar  idea,  and  called  it  the  method  of 
"synthetic  orders"  [WI  52];  we  would  now  call  this  a macro  expansion. 

The  A-0  "compiler"  was  improved  to  A-l  (January,  1955)  and  then 
to  A- 2 (August,  1955 ) ; the  original  implementors  were  Richard  K.  Ridgeway 
and  Margaret  H.  Harper.  Quite  a few  references  to  A-2  have  appeared  in 
the  literature  of  those  days  [HM  55>  HO  55,  HO  55',  MO  5*0  WA  5*+],  but 
these  authors  gave  no  examples  of  the  language  itself.  Therefore  it  will 
be  helpful  to  discuss  here  the  state  of  A-2  as  it  existed  late  in  1955, 
when  it  was  first  released  to  UNIVAC  customers  for  testing  [RR  55]*  As 
we  will  see,  the  language  was  quite  primitive  by  comparison  with  those 
we  have  been  studying,  and  this  is  why  we  choose  to  credit  Glennie  with 
the  first  compiler  although  A-0  was  completed  first;  yet  it  is  important 
to  understand  what  was  called  a "compiler"  in  195*0  in  order  to  appreciate 
the  historical  development  of  programming  languages. 

Here  is  how  TPK  would  have  looked  in  A-2  at  the  end  of  1955: 
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038038 

VTl 

«< 

II 

\ 

6. 

AA0040 

038038 

t'+y'  = y" 

7. 

AS0004 

038040 

400-y//  = t" 

8. 

OWN AC 0 

DEA003 

K00000 

KDOOOO 

F00912 

E001RG 

if  t"  > 0 , go  on  to  Op.  10 

000000 

QP01CN 

1RG000 

oo8o4o 

1CN000 

000010 

9- 

CMM000 

000001 

000188 

020238 

’ AAATOO  alarge  aaaaaa  aaaaaa'  = y" 

1RG000 

009000 

10. 

YT0036 

O38OOO 

Print  i,  y" 

11. 

GMM000 

000001 

000194 

200220 

Move  20  words  from  WS14  to  WS40 

1RG000 

011000 

» 


f 1 


12. 

GMMOCO 

000001 

000222 

200196 

Move  20  words  from  WSbO  to  WS16 

1RG000 

012000 

13. 

ALL012 

FOOOT^ 

1RG000 

013036 

Replace  i by  i+(-l)  and  go  to  Op.  2 

2RG000 

000037 

if  i -1 , otherwise  go  to  Op.  lb 

3RG000 

000006 

bRGOGO 

000007 

5RG000 

000006 

6RG000 

000007 

1CNOOO 

000002 

2CNOOO 

OOCOlb 

1RS000 

OOOO36 

2RS000 

000037 

lb. 

0WNAC0 

DEA002 

810000 

820000 

Rewind  tapes  1 and  2,  and  halt. 

900000 

900000 

1RG000 

OlbOOO 

^ENDA  INFO.J* 


There  were  60  words  of  working  storage,  and  each  floating-point  number 
used  two  words.  These  working  storages  were  usually  addressed  by  numbers 

00 .  02  , . . . , 58  , except  in  the  GMM  instruction  (move  generator)  when 
they  were  addressed  by  180  , 182  , . . . , 238  respectively;  see  operations 

1,  9>  U,  and  12.  Since  there  was  no  provision  for  absolute  value, 

4 I 2 

operations  2 and  3 of  this  program  find  V | a^Q | by  computing  ya . 

(The  A-2  compiler  would  replace  most  operators  by  a fully  expanded  subroutine, 
in  line;  this  subroutine  would  be  copied  anew  each  time  it  was  requested, 
unless  it  was  one  of  the  four  basic  floating-point  arithmetic  operations.) 
Since  there  was  no  provision  for  subscripted  variables,  operations  11 
and  12  shift  the  array  elemffl  - after  each  iteration. 

Most  arithmetic  instructions  were  specified  with  a three-address 
code,  as  shown  in  operations  2 thru  7«  But  at  this  point  in  the  development 
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of  A-2  there  was  no  way  to  test  the  relation  " > " without  resorting 
to  machine  language  — only  a test  for  equality  was  built  in  — so 
operation  8 specifies  the  necessary  UNIVAC  instructions.  (The  first 
word  in  operation  8 says  that  the  following  003  lines  contain  UNIVAC 
code.  Those  three  lines  extract  (E)  the  sign  of  the  first  numeric 
argument  (1RG)  using  a system  constant  in  location  912  , and  if  it 
was  positive  they  instruct  the  machine  to  go  to  program  operator  1CH  . 

The  next  two  lines  say  that  1RG  is  to  be  t"  (working  storage  40  ), 
and  that  1CN  is  to  be  the  address  of  operation  10.  The  " 008 " in  the 
1RG  specification  tells  the  compiler  that  this  is  operation  8;  such 
redundant  information  was  checked  at  compile  time.  Note  that  the 
compiler  would  substitute  appropriate  addresses  for  1RG  and  1CN 
in  the  machine  language  instructions.  Since  there  was  no  notation 
for  " 1RG+1  ",  the  programmer  had  to  supply  ten  different  parameter 
lines  in  operation  13 . 

By  1955,  A-2  had  become  more  streamlined,  and  the  necessity  for 
OWN  CODE  in  the  above  program  had  disappeared;  see  [PR  55]  for  a description 


of 

A-2  coding,  vintage  1955.  (Another  paper  [TH  55] 

also  appeared  at  that  time, 

pre 

senting  the  same 

example  program. ) Operations  7 

and  the  following  of 

the 

above  program  could  now  be  replaced  by 

7* 

QT0038 

00U000 

To 

op.  9 if  y"  > 4oo 

1CN000 

000009 

8. 

'QUOO38 

038000 

Go 

to  Cp.  10 

1CN000 

000010 

9- 

MV0008 

001038 

■> 

10. 

YTOO36 

038000 

n. 

MV0014 

0100U0 

12. 

mvooUo 

010016 

13- 

AALO36 

006006 

S Same  meaning  as  before, 

but  new  syntax. 

1CN000 

000002 

2CN000 

000014 

lb. 

RWS120 

000000 

ENDACO 

D INGA A 

O I 
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Laning  and  Zierler. 


Grace  Hopper  was  particularly  active  as  a spokesperson  for 
automatic  programming  during  the  1950's;  she  went  barnstorming 
throughout  the  country,  significantly  helping  to  accelerate  the 
rate  of  progress.  One  of  the  most  important  things  she 
accomplished  was  to  help  organize  two  key  symposia  on  the  topic,  in 
1954  and  1956,  under  the  sponsorship  of  the  Office  of  Naval  Research. 

These  symposia  brought  together  many  people  and  ideas  at  an  important 
time.  (On  the  other  hand,  it  must  be  remarked  that  the  contributions 
of  Zuse,  Curry,  Burks,  Mauchly,  B‘dhm,  and  Glennie  were  not  mentioned  at  either 
symposium,  and  Rutishauser ' s work  was  cited  only  once  --  not  quite 
accurately  [GO  54,  p.  76].  Communication  was  not  rampant'.) 

In  retrospect,  the  biggest  event  of  the  1954  symposium  on  automatic 
programming  was  the  announcement  of  a system  that  J.  Halcombe  Laning,  Jr.  and 
Niel  Zierler  had  recently  implemented  for  the  Whirlwind  computer  at  M.I.T. 
However,  the  significance  of  that  announcement  is  not  especially  evident 
from  the  published  proceedings  [NA  54],  97$  of  which  are  devoted  to 
enthusiastic  descriptions  of  assemblers,  interpreters,  and  1954-style 
"compilers".  We  know  of  the  impact  mainly  from  Grace  Hopper's  introductory 
remarks  at  the  1956  symposium,  discussing  the  past  two  years  of  progress: 

A description  of  Laning  and  Zierler' s system  of  algebraic 
pseudocoding  for  the  Whirlwind  computer  led  to  the  development 
of  Boeing's  BACAIC  for  the  70I,  FORTRAN  for  the  704,  AT-3  for 
the  Univac,  and  the  Purdue  System  for  the  Datatron  and  indicated 
the  need  for  far  more  effort  in  the  area  of  algebraic  translators. 

[HO  56] 

A clue  to  the  importance  of  Laning  and  Zierler 's  contribution  can  also 
be  found  in  the  closing  pages  of  a paper  by  John  Backus  and  Harlan  Herrick 
at  the  1954  symposium.  After  describing  IBM  701  Speedcoding  and  the 
tradeoffs  between  interpreters  and  "compilers",  they  concluded  by 
speculating  about  the  future  of  automatic  programming: 
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A programmer  might  not  be  considered  too  unreasonable  if  he 
were  willing  only  to  produce  the  formulas  for  the  numerical 
solution  of  his  problem,  and  perhaps  a plan  showing  how  the 
data  was  to  be  moved  from  one  storage  hierarchy  to  another, 
and  then  demand  that  the  machine  produce  the  results  for  his 
problem.  No  doubt  if  he  were  too  insistent  next  week  about 
this  sort  of  thing  he  would  be  subject  to  psychiatric 
observation.  However,  next  year  he  might  be  taken  more 
seriously.  [BH  5^+] 

After  listing  numerous  advantages  of  high-level  languages,  they  said: 
"Whether  such  an  elaborate  automatic-programming  system  is  possible 
or  feasible  has  yet  to  be  determined."  As  we  will  soon  see,  the  system 
of  Laning  and  Zierler  proved  that  such  a system  is  indeed  possible. 

Brief  mention  of  their  system  was  made  by  Charles  Adams  at  the 
symposium  [AL  5^-1;  but  the  full  user's  manual  [LZ  5^]  ought  to  be 
reprinted  some  day  because  their  language  went  so  far  beyond  what  had 
been  implemented  before.  The  programmer  no  longer  needed  to  know  much 
about  the  computer  at  all,  and  the  user's  manual  was  (for  the  first  time) 
addressed  to  a complete  novice.  Here  is  how  TPK  would  look  in  their 

v | N = (input), 
i =0, 
j = i+lj 
a ji  =v|  j, 
i = j, 

e =i-10.5, 

CP  1, 
i =10, 

y = F1(F11(a|i))+5(a|i)5, 
e =y-400, 

CP  5, 
z =999, 

PRINT  i,  z. 


system: 

1 

2 

I 1 
k 

5 . 

6 

1 

8 

2 2 
10 

n 

12 

±2 
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14  SP  4, 

15  3 PRINT  i,y. 

16-  4 i =i-l, 

r£  e=-0.5-i, 

18  CP  2, 


The  program  was  typed  on  a Flexowriter  which  punched  paper  tape 

and  had  a fairly  large  character  set  (including  both  upper  and  lower 

0 1 9 

case  letters);  at  M.I.T.  they  also  had  superscript  digits  , , ..., 
and  a vertical  line  | . The  language  used  the  vertical  line  to 

z Z 

indicate  subscripts;  thus  the  " 5(a[ip  " on  line  9 means  5a^  . 

A programmer  would  insert  his  eleven  input  values  for  the  TPK 
algorithm  into  the  place  shown  on  line  1;  then  they  would  be  converted 
to  binary  notation  and  stored  on  the  magnetic  drum  as  variables 
vx,v2,  ...,Vn  . If  the  numbers  had  a simple  arithmetic  pattern,  an 
abbreviation  could  also  be  used;  e.g., 

v|N  = 1 (.5)  2 (.25)  3.5  (1)  5.5 

would  set  (v.^,  - (l , 1.5  , 2 , 2.25  , 2.5  , 2.75  , 3 > 3 -25  , 3*5  , 4.5  , 5.5) 

If  desired,  a special  code  could  be  punched  on  the  Flexowriter  tape  in 
line  1,  allowing  the  operator  to  substitute  a data  tape  at  that  point 
before  reading  in  the  rest  of  the  source  program. 

Lines  2 thru  are  a loop  which  moves  the  variables  v^,  from 

the  drum  to  variables  aQ, ...,a1Q  in  core.  (All  variables  were  in  core 
unless  specifically  assigned  to  the  drum  by  an  ASSIGN  or  |N  instruction. 

This  was  an  advanced  feature  of  the  system  not  needed  in  small  problems.) 

The  only  thing  that  isn't  self-explanatory  about  lines  2 thru  J_  is  line  J_; 

" CP  k,  " means  "if  the  last  expression  computed  was  negative,  go  to  the 
instruction  labeled  k". 

— -i  • -r-il  J I 3 T.H  J L. -1- 1 ..i..  •> *1  . . n 


In  line  9,  F^  denotes  square  root  and  denotes  absolute  value. 

In  line  14,  " SP  " denotes  an  unconditional  jump.  (CP  and  SP  were  the 
standard  mnemonics  for  jumps  in  Whirlwind  machine  language.)  Thus,  except 
for  control  statements  — for  which  there  was  no  existing  mathematical 
convention  --  Laning  and  Zierler’s  notation  was  quite  easy  to  read. 
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Their  expressions  featured  normal  operator  precedence,  as  well  as 
implied  multiplication  and  exponentiation;  and  they  even  included  a 
built-in  Runge  - Kutta  mechanism  for  integrating  a system  of  differential 
equations  if  the  programmer  wrote  formulas  such  as 

Dx  = y + 1, 

Dy  = -x, 

where  D stands  for  d/dt  1 Another  innovation,  designed  to  help 
debugging,  was  to  execute  statement  number  100  after  any  arithmetic 
error  message,  if  100  was  a PRINT  statement. 

According  to  [LM  70] , Laning  first  wrote  a prototype  algebraic 
translator  in  the  summer  of  1952.  He  and  Zierler  had  extended  it  to  a 
usable  system  by  May,  1953>  when  the  Whirlwind  had  only  1024  l6-bit 
words  of  core  memory  in  addition  to  its  drum.  The  version  described  in 
[LZ  54]  utilized  2048  words  and  drum,  but  earlier  compromises  due  to 
such  extreme  core  limitations  caused  it  to  be  quite  slow.  The  source 
code  wa  ranslated  into  blocks  of  subroutine  calls,  stored  on  the  drum, 
and  after  being  transferred  to  core  storage  (one  equation's  worth  at  a 
time)  these  subroutines  invoked  the  standard  floating-point  interpretive 
routines  on  the  Whirlwind. 

The  use  of  a small  number  of  standard  closed  subroutines  has 
certain  advantages  of  logical  simplicity;  however,  it  also  often 
results  in  the  execution  of  numerous  unnecessary  operations. 

This  fact,  plus  the  frequent  reference  to  the  drum  required  in 
calling  in  equations,  results  in  a reduction  of  computing  speed 
of  the  order  of  magnitude  of  ten  to  one  from  an  efficient  computer 
program.  [AL  54,  p.  64] 

From  a practical  standpoint,  those  were  damning  words.  Laning  recalled, 
eleven  years  later,  that 

This  was  in  the  days  when  machine  time  was  king,  and  people-time 
was  worthless  (particularly  since  I was  not  even  on  the  Whirlwind 
staff).  ...  [The  program]  did  perhaps  pay  for  itself  a few  times 
when  a complex  problem  required  solutions  with  a twenty- four 
hour  deadline.  [LA  65] 
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In  a recent  search  of  his  files,  Laning  found  a listing  of  the 
Whirlwind  compiler's  first  substantial  application: 

The  problem  addressed  is  that  of  a three-dimensional  lead 
pursuit  course  flown  by  one  aircraft  attacking  another,  including 
the  fire  control  equations.  What  makes  this  personally  interesting 
to  me  is  tied  in  with  the  fact  that  for  roughly  five  years  previous 
to  this  time  the  [M.I.T.  Instrumentation]  Lab  had  managed  and 
operated  the  M.I.T.  Rockefeller  Differential  Analyzer  with  the 
principal  purpose  of  solving  this  general  class  of  problem. 

Un fortunately,  the  full  three  dimensional  problem  required  more 
integrators  than  the  RDA  possessed. 

My  colleagues  who  formulated  the  problem  were  very  skeptical 
that  it  could  be  solved  in  any  reasonable  fashion.  As  a challenge, 
Zierler  and  I sat  down  with  them  in  a 2-1/2  hour  coding  session, 
at  least  half  of  which  was  spent  in  defining  notation.  The  tape 
was  punched,  and  with  the  usual  beginner's  luck  it  ran  successfully 
the  first  time I Although  we  never  seriously  capitalized  on  this 
capability,  for  reasons  of  cost  and  computer  availability,  my  own 
ego  probably  never  before  or  since  received  such  a boost.  [LA  7-0 

The  lead-pursuit  source  program  consisted  of  79  statements,  including  29 
which  merely  assigned  initial  data  values,  and  also  including  seven  uses 
of  the  differential  equation  feature. 

Laning  describes  his  original  parsing  technique  as  follows: 

Nested  parentheses  were  handled  by  a sequence  of  generated 
branch  instructions  (sp).  In  a one-pass  operation  the  symbols 
were  read  and  code  generated  a symbol  at  a time;  the  actual 
execution  sequence  used  in-line  sp  orders  to  hop  about  from 
one  point  to  another.  The  code  used  some  rudimentary  stacks, 
but  was  sufficiently  intricate  that  I didn't  understand  it  without 
extreme  concentration  even  when  I wrote  it.  ...  Structured  programs 
were  not  known  in  19531 

The  notion  of  operator  precedence  as  a formal  concept  did  not 
occur  to  me  at  the  time;  I lived  in  fear  that  someone  would  write 
a perfectly  reasonable  algebraic  expression  that  my  system  would 
not  analyze  correctly.  [LA7r^] 
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Flans  for  a much  expanded  Whirlwind  compiler  were  dropped  when  the 
M.I.T.  Instrumentation  Lab  acquired  its  own  computer,  an  IBM  650. 

Laning  and  his  colleagues  Fhilip  C.  Hankins  and  Charles  P.  Werner 
developed  a compiler  called  MAC  for  this  machine  in  1957  and  1958. 
Although  MAC  falls  out  of  the  time  period  covered  by  our  story,  it 
deserves  brief  mention  here  because  of  its  unusual  three-line  format 
proposed  by  R.  H.  Battin  c.  1956,  somewhat  like  Zuse's  original  language. 
For  example,  the  statement 


Y = SQRT(ABS(A  ))  +5  A 


would  be  punched  on  three  cards.  Although  this  language  has  not  become 
widely  known,  it  was  very  successful  locally:  MAC  compilers  were  later 

developed  for  use  with  IBM  70U,  709*  7090  and  560  computers,  as  well  as 
the  Honeywell  h800  and  Hl800  and  the  CDC  36OO.  (See  [LM  70].)  "At  the 
present  time  [1976],  MAC  and  FORTRAN  have  about  equal  use  at  CSDL,  " 
according  to  [LA  7c];  here  CSDL  means  C.  S.  Draper  Laboratory,  the 
successor  to  M.I.T.  Instrumentation  Lab. 

But  we  had  better  get  back  to  our  story  of  the  early  days. 


TORT  RAM  0. 

During  the  first  part  of  195^*  John  Backus  began  to  assemble  a group 
of  people  within  IBM  to  work  on  improved  systems  of  automatic  programming 
(see  [BA  76]).  Shortly  after  learning  of  the  Laning  and  Zierler  system 
at  the  ONR  meeting  in  May,  Backus  wrote  to  Laning  that  "our  formulation 
of  the  problem  is  very  similar  to  yours:  however,  we  have  done  no 

programming  or  even  detailed  planning."  Within  two  weeks,  Backus  and  his 
co-workers  Harlan  Herrick  and  Irving  Ziller  visited  M.I.T.  in  order  to  see 
the  Laning/ zierler  system  in  operation.  The  big  problem  facing  them  was 
to  implement  such  a language  with  suitable  efficiency. 
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At  that  time,  most  programmers  wrote  symbolic  machine 
instructions  exclusively  (some  even  used  absolute  octal  or 
decimal  machine  instructions).  Almost  to  a man,  they  firmly 
believed  that  any  mechanical  coding  method  would  fail  to  apply 
that  versatile  ingenuity  which  each  programmer  felt  he  possessed 
and  constantly  needed  in  his  work.  Therefore,  it  was  agreed, 
compilers  could  only  turn  out  code  which  would  be  intolerably 
less  efficient  than  human  coding  (intolerable,  that  is,  unless 
that  inefficiency  could  be  buried  under  larger,  but  desirable, 
inefficiencies  such  as  the  programmed  floating-point  arithmetic 
usually  required  then) . ... 

[Our  development  group]  had  one  primary  fear.  After  working 
long  and  hard  to  produce  a good  translator  program,  an  important 
application  might  promptly  turn  up  which  would  confirm  the  views 
of  the  sceptics:  ...  its  object  program  would  run  at  half  the 

speed  of  a hand-coded  version.  It  was  felt  that  such  an  occurrence, 
or  several  of  them,  would  almost  completely  block  acceptance  of 
the  system.  [BH  64] 


By  November  of  1954,  Backus's  group  had  specified  "The  IBM  Mathematical 
FORmula  TRANslating  system,  FORTRAN".  (Almost  all  the  languages  we  shall 
discuss  from  now  on  had  acronyms.)  The  first  paragraph  of  their  report 
[IB  54]  emphasizes  that  previous  systems  had  offered  the  choice  of  easy 
coding  and  slow  execution  or  laborious  coding  and  fast  execution,  but 
FORTRAN  would  provide  the  best  of  both  worlds.  It  also  places  specific 
emphasis  on  the  IBM  704;  machine  independence  was  not  a primary  goal, 
although  a concise  mathematical  notation  "which  does  not  resemble  a machine 
language"  was  definitely  considered  important.  Furthermore  they  stated 
that  "each  futi  re  IBM  calculator  should  have  a system  similar  to  FORTRAN 
accompanying  it." 

It  is  felt  that  FORTRAN  offers  as  convenient  a language  for  stating 
problems  for  machine  solution  as  - S now  known.  . . . After  an  hour 
course  in  FORTRAN  notation,  the  average  programmer  can  fully  under- 
stand the  steps  of  a procedure  stated  in  FORTRAN  language  without 
any  additional  comments.  [IB  54] 
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They  went  on  to  describe  the  considerable  economic  advantages  of 
programming  in  such  a language. 


Perhaps  the  reader  thinks  he  knows  FORTRAN  already;  it  is  certainly 
the  earliest  high-level  language  that  is  still  in  use.  However,  few 
people  have  seen  the  original  1954  version  of  FORTRAN,  so  it  is 
instructive  to  study  TPK  as  it  might  have  been  expressed  in  "FORTRAN  0" : 

1 DIMENSION  A (11) 

2 READ  A 

3 2 DO  3,8,11  J = 1,11 

4 3 1 = 11-  J 

5 y = sqrt(abs(a(i+i) ) ) + 5*a(i+i)**3 

6 IF  (400.  > = Y)  8,4 

7 k PRINT  1,999. 

8 GO  TO  2 

9 8 PRINT  I, Y 

10  11  STOP 

I 

The  READ  and  PRINT  statements  do  not  mention  any  FORMATS,  although  an 
extension  to  format  specification  was  contemplated  [p.  2-  ];  programmer- 
defined  functions  were  also  under  consideration  [p.  27].  The  DO  statement 
in  line  3 means,  "Do  statements  3 thru  8 and  then  go  to  11  the 
abbreviation  " DO  8 J = 1, 11  " was  also  allowed  at  that  time,  but  the 
original  general  form  is  shown  here  for  fun.  Note  that  the  IF  statement 
was  originally  only  a two-way  branch  (line  6);  the  relation  could  be  = , 

> , or  >=  . On  line  5_  we  note  that  function  names  need  not  end  in  F ; 
they  were  required  to  be  at  least  three  characters  long,  and  there  was 
no  maximum  limit  (except  that  expressions  could  not  be  longer  than  750 
characters).  Conversely,  the  names  of  variables  were  restricted  to  be 
at  most  two  characters  long  at  this  time;  but  this  in  itself  was  an 
innovation,  FORTRAN  being  the  first  language  in  which  a variable's 
name  could  be  larger  than  one  letter,  contrary  to  established 
mathematical  conventions.  Note  that  mixed  mode  arithmetic 
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was  allowed.,  the  compiler  was  going  to  convert  " 5 " to  "5.0"  in  line  5- 
A final  curiosity  about  this  program  is  the  GO  TO  statement  on  line  8; 
this  did  not  begin  the  DO  loop  all  over  again,  it  merely  initiated  the 
next  iteration. 

Several  things  besides  mixed-mode  arithmetic  were  allowed  in  FORTRAN  0 
but  withdrawn  during  implementation,  notably  (a)  subscripted  subscripts 
to  one  level,  such  as  A(M(l,  J),  N(K,  L) ) were  allowed;  (b)  subscripts 
of  the  form  N*I+J  were  allowed,  provided  that  at  least  two  of  the 
variables  N,  I,  J were  declared  to  be  "relatively  constant”  (i.e., 
infrequently  changing) ; (c)  a RELABEL  statement  was  intended  to  permute 

array  indices  cyclically  without  physically  moving  the  array  in  storage. 

For  example,  " RELABEL  A(3)  " was  to  be  like  setting 
(A(1),A(2),A(3),  ...,A(n))  - (a(3),  . . .,  A(n),A(l),A(2))  . 

Incidentally,  statements  were  called  formulas  throughout  the  1951 
document;  there  were  arithmetic  formulas,  DO  formulas,  GO  TO  formulas, 
etc.  Similar  terminology  had  been  used  by  Bohm,  while  Laning  and 
Zierler  and  Glennie  spoke  of  "equations";  Grace  Hopper  called  them 
"operations".  Furthermore,  the  word  "compiler"  is  never  used  in  [IB  5*0; 
there  is  a FORTRAN  language  and  a FORTRAN  system,  but  not  a FORTRAN 
compiler. 

The  FORTRAN  0 document  represents  the  first  attempt  to  define  the 
syntax  of  a programming  language  rigorously;  Backus's  important  notation 
[BA  59]  which  eventually  became  " BNF"  [KN  61]  can  be  seen  in  embryonic 
form  here. 

With  the  FORTRAN  language  defined,  it  "only"  remained  to  implement 
the  system.  It  is  clear  from  reading  [IB  5l]  that  considerable  plans 
had  already  been  made  towards  the  implementation;  however,  the  full  job 
took  2.5  more  years  (l8  man-years),  so  we  shall  leave  the  IBM  group  at 
work  while  we  consider  other  developments. 

BTOokejr’  s^  Autocode. 

Back  in  Manchester,  R.  A.  Brooker  introduced  a new  type  of  Autocode  for 
the  Mark  I machine.  This  language  was  much  "cleaner"  than  Glennie's, 
being  nearly  machine- independent  and  using  programmed  floating-point 
arithmetic,  but  it  allowed  only  one  operation  per  line,  there  were  few 


i 


1 


m 
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mnemonic  names,  and  there  was  no  way  for  a user  to  define  subroutines. 

The  first  plans  for  this  language,  as  of  March  195l>  appeared  in  [BR  55 ], 
and  the  language  eventually  implemented  [BR  56,  pp.  155-157]  was  almost 
the  same.  Brooker's  emphasis  on  economy  of  description  was  especially 
noteworthy:  "What  the  author  aimed  at  was  two  sides  of  a foolscap  sheet 

with  possibly  a third  side  to  describe  an  example."  [BR  55] 

The  float’ ng-point  variables  in  Brooker's  Mark  I Autocode  are  called 
vl, v2, . . . and  the  integer  variables  — which  may  be  used  also  as 
indices  (subscripts)  — are  called  nl,n2, ...  . The  Autocode  for  TPK  is 
easily  readable  with  only  a few  auxiliary  comments,  given  the  memory 
assignments  ai  = v1+i  , y = v.^  , i = ng  : 


1 nl  = 1 

vnl  = I 

nl  = nl+1 
jl, 11  > nl 
nl  = 11 

2 * n2  = nl-1 

vl2  = vnl 
j3>  vl2  >0*0 
vl2  = 0-0-V12 

3 vl2  = Fl(vl2) 

vl3  = 5 *0  8 vnl 
vl3  = vnl  g vl3 
vl3  - vnl  ® vl3 
vl2  = vl2  + vl3 

j 4,  vl2  > U00»0 
* vl2  = vl2 

J5 

1+  * vl2  = 999*0 

5 nl  = nl-1 

j2,  nl  > 0 

H 

(jl) 


sets  n^  = 1 
reads  input  into  v 


jumps  to  1 if  n1  < 11 


prints  i = n^-1 


sets  v12  = |v12 

(vi2  =^hl) 


13  “ ' “i' 

(y  = f(a±)) 

prints  y 

prints  999 

tests  for  last  cycle 
halt 

starts  programme 


61 


1 


I 


The  final  instruction  illustrates  an  interesting  innovation:  An 

instruction  or  group  of  instructions  in  parentheses  was  obeyed 
immediately,  rather  than  added  to  the  program.  Thus  " (jl)  ” jumps 
to  statement  1. 

This  language  is  not  at  a very  high  level,  but  Brooker's  main 
concern  was  simplicity  and  a desire  to  keep  information  flowing 
smoothly  to  and  from  the  electrostatic  high-speed  memory.  Mark  I's 
electrostatic  memory  consisted  of  only  512  20-bit  words,  and  it  was 
necessary  to  make  frequent  transfers  from  and  to  the  32K-word  drum; 
floating-point  subroutines  could  compute  while  the  next  block  of 
program  was  being  read  in.  Thus  two  of  the  principal  difficulties 
facing  a programmer  --  scaling  and  coping  with  the  two-level  store  -- 
wore  removed  by  his  Autocode  system,  and  it  was  heavily  used.  For 
example : 

Since  its  completion  in  1955  the  Mark  I Autocode  has  been  used 
extensively  for  about  12  hours  a week  as  the  basis  of  a computing 
service  for  which  customers  write  their  own  programs  and  post 
them  to  us.  [BR  58,  p.  16] 

Gary  E.  Felton,  who  developed  the  first  Autocode  for  the  Ferranti 
PEGASUS,  says  in  [FE  60]  that  its  specification  "clearly  owes  much  to 
Mr.  R.  A.  Brooker."  Incidentally,  Brooker's  next  Autocode  (for  the 
Mark  II  or  'Mercury'  computer,  first  delivered  in  1957)  was  considerably 
more  ambitious;  see  [BR  58,  BR  58',  BR  60]. 
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Russian  Programing  Programs. 

Work  on  automatic  programming  began  in  Russia  at  the  Mathematical 
Institute  of  the  Soviet  Academy  of  Sciences,  and  at  the  Academy's 
computation  center,  which  originally  was  part  of  the  Institute  of  Exact 
Mechanics  and  Computing  Technique.  The  early  Russian  systems  were 
appropriately  called  Programming  Programs  [ Programmiruioshchye  Programmy] 

--  or  TTTT  for  short.  An  experimental  program  TTT-1  for  the  STRELA  computer 

A v 

was  constructed  by  E.  Z.  Liubimskii  and  S.  S.  Kamynin  during  the  summer 
of  195^;  and  these  two  authors,  together  with  M.  R.  Shura-Bura, 

A 

E.  L.  Lukhovitskaia,  and  V.  S.  Shtarkman,  completed  a production  compiler 
called  TTTT-2  in  February,  1955.  This  compiler  is  described  in  [KL  58]. 
Meanwhile,  A.  P.  Ershov  began  in  December  195^  to  design  another  programming 
program,  for  the  BESM  computer,  with  the  help  of  L.  N.  Korolev, 

A 

L.  D.  Panova,  V.  D.  Poderiugin  and  V.  M.  Kurochkin;  this  compiler,  called 
simply  TUT,  was  completed  in  March,  1956,  and  it  is  described  in  Ershov's 
book  [ER  58].  A review  of  these  developments  appears  in  [KO  58], 

In  both  of  these  cases,  and  in  the  later  system  TTll-5  completed  in  1957 
(see  [ER  58']),  the  language  was  based  on  a notation  for  expressing 

A A 

programs  developed  by  A.  A.  Liapunov  in  1955*  Liapunov's  operator 


schemata  [LJ  58]  provide  a concise  way  to  represent  program  structure 
in  a linear  manner;  in  some  ways  this  approach  is  analogous  to 
the  ideas  of  Curry  we  have  already  considered,  but  it  is  somewhat 
more  elegant  and  it  became  widely  used  in  Russia. 

Let  us  consider  first  how  the  TPK  algorithm  (exclusive  of  input- 
output)  can  be  described  in  TTU-2.  The  overall  operator  scheme  for  the 
program  would  be  written 

\ Z2  S Rb  I"""  ^1^LV9r  yl  ^0  i A11  r12  R13  L_  'pi  • 

n 

Here  the  operators  are  numbered  1 thru  ih  ; and  n L_  mean 

m 

respectively  " go  to  operator  n if  true,  go  to  operator  m if  false  ”, 
i 

while  1 J are  the  corresponding  notations  for  "coming  from  operator  i". 
i 

This  operator  scheme  was  not  itself  input  to  the  programming  program 
explicitly,  it  would  be  kept  by  the  programmer  in  lieu  of  a 
flowchart.  The  details  of  operators  would  be  written  separately  and 
input  to  TTr-2  after  dividing  them  into  operators  of  types  R (relational), 

A (arithmetic),  Z (dispatch),  F (address  modification), 

0 (restoration),  and  N (nonstandard,  i.e.,  machine  language).  In  the 
above  case,  the  details  are  essentially  this: 


V 

p-l  ; 6,  5 

[if  px  is 

true  go  to  6 else  to  5 ] 

R,. 

( 

p2;  8,  10 

[if  p2  is 

true  go  to  8 else  to  10] 

r13' 

p3;  ik,  2 

[if  p5  is 

true  go  to  ll  else  to  2] 

pr 

c3  < V2 

[0  < x] 

V 

%<v3 

[U00  < y] 

p3- 

v6  < c3 

[i  < 0] 

Ar 

c6  = v6 

[10  = i , 

i.e.,  set  i equal  to  10] 

V 

V1  = v2 

[at  = x] 

V 

CVJ 

> 

II 

1 

ro 

o 

[0-x  = x] 
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(/  v2)+(o5*v1*v1*v1)  = v5  [(/  x)+(5*a..ai.ai)  = y] 


Ag. 

v6  = V c2  = v5 

[i  = b^  999  = c±  ] 

A10‘ 

ii 

tT 

> 

ii 

VO 

> 

[i  = b.,  y = c.] 

An* 

V.--C.  = vc 

o 1 6 

[i-1  = i] 

V 

vx;  3>  6 

.[dispatch  to  special  cell,  in  operators  3 thru  6] 

hr 

v,;  2.  lo 

[modify  addresses  depending  on  parameter  i,  in 
operators  2 thru  10] 

V 

BF  11 

[go  to  operator  11] 

Nlf 

OST 

[ stop ] 

Dependence  or  parameter 

v6*  vvi>  -1;  v V +2 

[when  i changes,  v.^  goes  down  by  1,  thru  v<-  go  up 

cl* 

.1-101 

[1] 

C2 ' 

■999-105 

[999] 

c3 " 

0 

<V 

.1+-105 

[too] 

c5  ’ 

.5-101 

[5] 

Working  cells : 100, 119 

[compiled  program  can  use  locations  100-119  for  temp 
storage] 

V 

130 

[initial  address  of  a^] 

V 

131 

[address  of  x] 

V 

132 

[address  of  y] 

V 

133 

[initial  address  of  b^] 

Vc  • 

13b 

[initial  address  of  c^] 

V 

13  b 

[address  of  i] 

Operator  1 initializes  i , then  operators  2 thru  1J  are  the  loop  on  i . 
Operator  2 moves  a-  to  a fixed  cell,  and  makes  sure  that  operators  3 
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thru  6 use  this  fixed  cell;  this  programmer- supplied  optimization 
means  that  fewer  addresses  in  instructions  have  to  he  modified  when 
i changes.  Operators  3 thru  5 set  x = | a^ | , and  operator  6 sets 
y = f(a^)  . (Note  the  parentheses  in  operator  6;  precedence  was  not 
recognized.)  Operators  7 thru  10  store  the  desired  outputs  in  memory; 
operators  11  and  12  decrease  i and  appropriately  adjust  the  addresses 
of  quantities  that  depend  on  i . Operators  13  and  ll  control  looping 
and  stopping. 

The  algorithms  used  in  TTTT-2  are  quite  interesting  from  the  standpoint 
of  compiler  history;  for  example,  they  avoided  the  recomputation  of 
common  subexpressions  within  a single  formula.  They  also  produced 
efficient  code  for  relational  operators  compounded  from  a series  of 
elementary  relations,  so  that,  for  example, 

(Pp  V (p2*Pj)  v^)-p5  vp6 


Ershov's  TfTT  language  improves  on  HTf-2  in  several  respects,  notably 
(a)  the  individual  operators  need  not  be  numbered,  and  they  may  be 
intermixed  in  the  natural  sequence;  (b)  no  address  modification  need 
be  specified,  and  there  is  a special  notation  for  loops;  (c)  the 
storage  for  variables  is  allocated  semi -automatic ally;  (d)  operator 
precedence  can  be  used  to  reduce  the  number  of  parentheses  within 
expressions.  The  TPK  algorithm  looks  like  this  in  TTTT: 
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1 Massiv  a (11  lacheek)  [declares  an  array  of  11  cells] 

2 a.Q  = 0 [address  in  array  a] 

a.  = -l-j+10  [address  in  array  a depending  on  j ] 

J 

— j ’ jnach  = Q’  ^kon  = ^ [information  on  loop  indexes] 

0,  11,  10,  5>  y>  ^00,  999 > i [list  of  remaining  constants  and  variables] 
6 (Ma,  080, 0,  aQ) ; (Mb,0, 01, 0) ; 

* 

1 [ 10- j =>  i;  / mod  a +5  x =*  y; 

j J J 

0101 

8 R(y,  0102;  | (1+00,  <*>)); 

0103 

9 1 Vyd  i,  * 0;  Vyd  999,  =»  0;  j ; 

0101 

10  | Vyd  i,  =»  0;  Vyd  y,  =>  0;  \ ];  STOP 

0102  0103 


After  declarations  on  lines  1 thru  5,  the  program  appears  here  on  lines  6 

thru  10.  In  TTTf  each  loop  was  associated  with  a different  index  name,  and 

the  linear  dependence  of  array  variables  on  loop  indices  was  specified 

as  in  line  note  that  a.  does  not  mean  the  j-th  element  of  a , it 

means  an  element  of  a which  depends  on  j . The  commands  in  line  6 

are  BESM  machine  language  instructions  which  read  11  words  into  memory 

starting  at  aQ  . Line  shows  the  beginning  of  the  loop  on  j , which 

ends  at  the  " ] " on  line  10;  all  loop  indices  must  step  by  +1  . (The 

initial  and  final-plus- one  values  for  the  j loop  are  specified  on  line  k. ) 

Line  8 is  a relational  operator  which  means,  "If  y is  in  the  interval 

(L00,°°)  , i.e.,  if  y > 100  , go  to  label  0101  ; otherwise  go  to  0102 

Labels  were  given  as  hexadecimal  numbers,  and  the  notation  L indicates 

n 

the  program  location  of  label  n . The  " Vyd " instruction  in  lines  2 and- 
10  means  convert  to  decimal,  and  " , =»  0 " means  print.  Everything 
else  should  be  self-explanatory. 
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The  Russian  computers  had  no  alphabetic  input  or  output,  so  the 
programs  written  in  TRT-2  and  TTTT  were  converted  into  numeric  codes. 

This  was  a rather  tedious  and  intricate  process,  usually  performed  by 
two  specialists  who  would  compare  their  independent  hand-transliterations 
in  order  to  prevent  errors.  As  an  example  of  this  encoding  process, 
here  is  how  the  above  program  would  actually  have  been  converted  into 
BESM  words  in  the  form  required  by  TTlf.  (The  hexadecimal  digits  were 
written  0,1, ...,9,0,1, ...,5  • A 39-bit  word  in  BESM  could  be  represented 
either  in  instruction  format, 


bbh  bqhh  bqhh  bqhh 


where  b denotes  a binary  digit  (0  or  1)  , q a quaternary  digit 
(0 , 1 , 2 , or  3 ),  and  h a hexadecimal  digit;  or  in  floating-binary 
numeric  format, 

+ 2k  , hh  hh  hh  hh 

where  k is  a decimal  number  between  -32  and  +31  inclusive.  Both  of 
these  representations  were  used  at  various  times  in  the  encoding  of  a 
TUT  program,  as  shown  below. ) 


Location  Contents 


Meaning 


07 

000 

0000 

0000 

0000 

08 

000 

0000 

0000 

0013 

09 

000 

0000 

0000 

0015 

00 

000 

0000 

0000 

0012 

01 

000 

0000 

0000 

0025 

02 

000 

0000 

0000 

00l2 

03 

000 

0000 

0000 

0295 

oC 

000 

0000 

0000 

0215 

05 

000 

0000 

0000 

0235 

10 

015 

0000 

0001 

0000 

li 

000 

1001 

0000 

0000 

12 

21, 

00  00  00  00 

13 

22, 

ll  00  00  00 

l! 

000 

0015 

0016  0000 

- 


no  space  needed  for  special  subroutines 
last  entry  in  array  descriptor  table 
first  entry  for  constants  and  variables 
last  entry  for  constants  and  variables 
base  address  for  encoded  program  scheme 
last  entry  of  encoded  program 
base  address  for  "block  y " 
base  address  for  "block  a " 
base  address  for  "block  3 " 
a = array  of  size  11 

coefficient  of  -1  for  linear  dependency 

aQ  = 0 relative  to  a 

a.  = -1-j  +10  relative  to  a 
J 

j = loop  index  from  0 to  11 


71 


Location 

Contents 

Meaning 

15 

2-52,  00  00  00  00 

0 

16 

at 

lo  00  00  00 

11 

17 

at 

00  00  00  00 

10 

18 

25, 

60  00  00  00 

5 

19 

2y, 

28  00  00  00 

400 

10 

210, 

, 59  20  00  00 

999 

ii 

000 

0000  0000  0000 

i 

12 

000 

0000  0000  0000 

y 

50 

016 

0080  0000  0012 

(Ma  , 080 , 0 , a^ 

31 

017 

0 

0 

0 

0 

0 

0 

0 

HI 

0 

0 

0 

0 

(Mb  , 0 , 01 , 0) 

32 

018 

0014  0000  0000 

h 

10  - j => 

33 

2°, 

17  04  14  08 

3k 

2°, 

11  53  52  15 

i / mod  a . 
+ 5 x a*! 
5 - y ° 

35 

2°, 

05  18  09  13 

36 

2°, 

OS  08  12  00 

37 

018 

0000  0012  0102 

R(y,  0102; 

38 

008 

0019  0000  0101 

Old 

| (Uoo,  -) ) 

39 

018 

0101  0000  0000 

1 

30 

2°, 

54  ll  07  00 

Old 

Vyd  i >=*  0 

3l 

2°, 

54  10  07  00 

Vyd  999  >=>  0 

32 

Oil 

0000  0000  0105 

0105 

r 

33 

018 

0102  0000  0000 

I 

3C 

2°, 

54  ll  07  00 

0102 

Vyd  i ,=»  0 

35 

2°, 

54  12  07  00 

Vyd  y ,=>  0 

40 

018 

0105  0000  0000 

| 

41 

015 

1355  1355  1355 

0103 

] 

42 

015 

0000  0000  0000 

STOP 

w 


~r 


* 


The  BESM  had  1021+  words  of  core  memory,  plus  some  high-speed 
read-only  memory,  and  a magnetic  drum  holding  5 x 1024  words.  The  TTTT 
compiler  worked  in  three  passes  (formulas  and  relations,  loops,  final 
assembly),  and  it  contained  a total  of  1200  instructions  plus  150 
constants.  Detailed  specifications  of  all  its  algorithms  were  published 
in  [ER  58];  Ershov  was  aware  of  Rutishauser ' s work  [p.  9],  but  he  gave 
no  other  references  to  non-Russian  sources. 


A Western  Development. 

Computer  professionals  at  the  Boeing  Airplane  Company  in  Seattle, 
Washington,  felt  that  "In  this  jet  age,  it  is  vital  to  shorten  the  time 
from  the  definition  of  a problem  to  its  solution."  So  they  introduced 
BACAIC,  the  Boeing  Airplane  Company  Algebraic  Interpretive  Computing 
system  for  the  IBM  7 01  computer. 

BACAIC  was  an  interesting  language  and  compiler  developed  by 
Mandalay  Grems  and  R.  E.  Porter,  who  began  work  on  the  system  in  the 
latter  part  of  195*+;  they  presented  it  at  the  Western  Joint  Computer 
Conference  held  in  San  Francisco,  in  February,  1956  [GP  56].  Although 
the  " I"  in  BACAIC  stands  for  "Interpretive",  their  system  actually 
translated  algebraic  expressions  into  machine  language  calls  on 
subroutines,  with  due  regard  for  parentheses  and  precedence,  so  we 
would  now  call  it  a compiler. 

The  BACAIC  language  was  unusual  in  several  respects,  especially  in 
its  control  structure  which  assumed  one-level  iterations  over  the  entire 
program;  a program  was  considered  to  be  a nearly  straight-line  computation 
to  be  applied  to  various  "cases"  of  data.  There  were  no  subscripted 
variables;  however,  the  TPK  algorithm  could  be  performed  by  inputting 
the  data  in  reverse  order  using  the  following  program: 
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1 


1.  I-K1*I 

2.  X 

3.  WHN  X GRT  K2  USE  5 

4.  K2-X*2 

5 . SRT  X + K3  . X FWR  K4 

6.  WHN  5 GRT  K5  USE  8 

7.  TRN  9 

8.  K6*5 

9-  TAB  1 5 

Here  " *"  is  used  for  assignment,  " . " 
are  given  single-letter  names  (except 
by  KL  thru  K99  • The  above  program 
input  data: 


for  multiplication;  variables 
K),  and  constants  are  denoted 
is  to  be  used  with  the  following 


Case  1. 

Case  2. 
Case  3 . 


KL  = 1.0 
I = 11.0 
X = a9 
X = a8 


K2  = 0.0 

X = aio 


K3  = 5.0 


Kb  = 3 .0  K5 


Case  11.  X = aQ  . 


400.0  K6  = 999.0 


Data  values  are  identified  by  name  when  input;  all  variables  are  zero 
initially,  and  values  carry  over  from  one  case  to  the  next  unless  changed. 
For  example,  expression  1 means  " 1-1  - I ",  so  the  initial  value  I = 11 
needs  to  be  input  only  in  Case  1. 

Expressions  2,  J>,  4 ensure  that  the  value  of  expression  2 is  the 
absolute  value  of  X when  we  get  to  expression  5.  (The  " 2"  in 
expression  4 means  expression  2,  not  the  constant  2 .)  Expression  5 
therefore  has  the  value  f(X)  . 

A typical  way  to  use  BACAIC  was  to  print  the  values  associated  with 
all  expressions  1,2, ...  ; this  was  a good  way  to  locate  errors. 

Expression  7 in  the  above  program  is  an  unconditional  jump;  expression  9 
says  that  the  value  of  I and  expression  5 should  be  printed. 

The  BACAIC  system  was  easy  to  learn  and  to  use,  but  the  language 
was  too  restrictive  for  general-purpose  computing.  One  novel  feature 
was  its  "check-out  mode",  in  which  the  user  furnished  hand- calculated  data 
and  the  machine  would  print  out  only  the  discrepancies  it  found. 
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According  to  [BE  57 ]>  BACAIC  became  operational  also  on  the 
IBM  650  computer,  in  August  of  1956. 


Kcmpilers. 


Another  independent  development  was  taking  place  almost  simultaneously 
at  the  University  of  California  Radiation  Laboratory  in  Livermore, 

California;  this  work  has  apparently  never  been  published,  except  as  an 
internal  report  [EK  55].  In  195*9  A.  Kenton  Elsworth  began  to  experiment 
with  the  translation  of  algebraic  equations  into  IBM  701  machine  language, 
and  called  his  program  KOMPILER  1;  at  that  time  he  dealt  only  with 
individual  formulas,  without  control  statements  or  constants  or  input/output. 
Elsworth  and  his  associates  Robert  Kuhn,  Leona  Schloss,  and  Kenneth  Tiede 
went  on  to  implement  a working  system  named  KOMPILER  2 during  the  following 
year.  This  system  is  somewhat  similar  in  flavor  to  TTTT-2,  except  that  it 
is  based  on  flow  diagrams  instead  of  operator  schemata.  They  characterized 
its  status  in  the  following  way: 


In  many  ways  Kompiler  is  an  experimental  model;  it  is  therefore 
somewhat  limited  in  applications.  For  example  it  is  designed  to 
handle  only  full-word  data  and  is  restricted  to  fixed-point 
arithmetic.  At  the  same  time  every  effort  was  made  to  design  a 
workable  and  worthwhile  routine:  the  compiled  code  should  approach 

very  closely  the  efficiency  of  a hand-tailored  code;  learning  to 
use  it  should  be  relatively  easy;  compilation  itself  is  very 
fast.  [EK  55] 


In  order  to  compensate  for  the  fixed-point  arithmetic,  special 
features  were  included  to  facilitate  scaling.  As  we  will  see,  this  is 
perhaps  KOMPILER  2's  most  noteworthy  aspect. 

To  solve  the  TPK  problem,  let  us  first  agree  to  scale  the  numbers 
by  writing 


a o-10 

A.  = 2 a. 
1 x 


Y = 


2-10  y 


I = 2"?5  i 


Furthermore  we  will  need  to  use  the  scaled  constants 

V = 5*2'5  , F = l00»2~10  , N = 999*  2_1°  , W = 1*2" 

The  next  step  is  to  draw  a special  kind  of  flow  diagram  for  the  program: 


,-35 


75 


T 


Read  values  of  constants  and  initial 
value  of  I from  a data  card. 


Read  Aq,  ...,A^q  from  two  more  data  cards 


Calculate  Y . 


Go  to  6 if  100  > y . 


Set  y to  999 . 


Print  answer. 


Decrease  i by  1 . 

Decrease  address  of  by  2 
wherever  it  appears. 


Return  to  3 if  i > 0 . 


Stop  the  machine 


The  third  step  is  to  assign  the  data  storage,  for  example  as  follows: 


► 


6151,  6?  5 Y , 65  = V , 67  = F , 69  = N , 71  s W; 
81  = Aq  , 83  S ^ , . . . , 101  s A^  . 


(Addresses  in  the  IBM  7 01  go  by  half  words,  but  variables  in  KOMPILER  2 
occupy  full  words.  Address  6l  denotes  halfwords  60  and  6l  in  the 
"second  frame"  of  the  memory.) 

The  final  step  is  to  transcribe  the  flow-diagram  information  into 
a fixed  format  designated  for  keypunching.  The  source  input  to 
KOMPILER  2 has  two  parts:  the  so-called  "flow  diagram  cards",  one 

card  per  box  in  the  flow  diagram,  and  the  "algebraic  cards",  one  per 
complex  equation.  In  our  case  the  flow  diagram  cards  are 


1CARD 

61 

2 

235 

0 

103  310 

310  135 

2 CARD 

81 

2 

310  310 

310  310 

310  310 

3 CALC 

101 

8 

65 

101  8 

63 

1TRPL 

67 

65 

6 

5 PLUS 

69 

63 

6PRNT 

61 

63 

2 

1 

35  10 

7MINS 

71 

61 

61 

8DECR 

2 

9TRPL 

61 

z 

3 

10 STOP 

0 61 

310  95  lb 


and  the  algebraic  cards  are 

1*ACARD 

2*APRNT 

3ASRTAABSA. -05+VA3 .+13=Y 

Here  is  a free  translation  of  the  meaning  of  the  flow  diagram  cards: 

1.  Read  data  cards  into  locations  beginning  with  61  in  steps  of  2 . The 

words  of  data  are  to  be  converted  using  respective  scale  codes  235,0,103, 
...,0  ; stop  reading  cards  after  the  beginning  location  has  become  6l  , 
i.e.,  immediately.  (The  scale  code  ddbb  means  to  take  the  10-digit 


;i 
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data  as  a decimal  fraction,  multiply  by  10^  , convert  to  binary, 
and  divide  by  2°^  . In  our  case  the  first  input  datum  will  be 
punched  as  1000000000  , and  the  scale  code  235  means  that  this 
is  regarded  first  as  ( 10. 00000000 )-,  n and  eventually  converted  to 
(.00. . .01010)2  = 10*2  , the  initial  value  of  I . The  initial 

value  of  N , with  its  scale  code  3 10  , would  therefore  be  punched 
9990000000  . Up  to  seven  words  of  data  are  punched  per  data  card. ) 

2.  Read  data  cards  into  locations  beginning  with  8l  in  steps  of  2 . 

The  words  of  data  are  to  be  converted  using  respective  scale  codes 
310, 310, .. .,310  ; stop  reading  cards  after  the  beginning  location 
has  become  95  . The  beginning  location  should  advance  by  It 
between  data  cards  (hence  exactly  two  cards  are  to  be  read). 

3.  Calculate  a formula  using  the  variables  in  the  respective  locations 
101  (which  changes  at  step  8);  65;  101  (which  changes  at  step  8); 
and  63. 

4.  If  the  contents  of  location  67  minus  the  contents  of  location  63 
is  nonnegative,  go  to  step  6. 

5.  Store  the  contents  of  location  69  in  location  63  . 

6.  Print  locations  6l  through  63 , with  2 words  per  line  and  1 line 
per  block.  The  respective  scale  factors  are  35  and  10  . 

7.  Subtract  the  contents  of  location  71  from  the  contents  of  location  6l 
and  store  the  result  in  location  6l . 

8.  Decrease  all  locations  referring  to  step  8 (cf.  step  3 ) hy  2 . 

9.  If  the  contents  of  location  61  is  nonnegative,  go  to  step  3 . 

10.  Stop  the  machine. 

The  first  two  algebraic  cards  in  the  above  example  simply  cause  the 
library  subroutines  for  card  reading  and  line  printing  to  be  loaded  with 
the  object  program.  The  third  card  is  used  to  encode 

V|Ai|  • 2~5  + VAi  • 215  = Y . 

The  variable  names  on  an  algebraic  card  are  actually  nothing  but  dummy 
placeholders,  since  the  storage  locations  must  be  specified  on  the 
corresponding  CALC  card.  Thus,  the  third  algebraic  card  could  also 
have  been  punched  as 


3 ASRTAABSX. -05+XX3 .+13=x 


without  any  effect  on  the  result. 

KOMPILER  2 was  used  for  several  important  production  programs 
at  Livermore.  By  1959  it  had  been  replaced  by  KOMPILER  3>  a rather 
highly  developed  system  for  the  IBM  "JOb  which  used  three-line  format 
analogous  to  that  of  MAC  (but  apparently  designed  independently). 


During  1955  and  1956,  E.  K.  Blum  at  the  U.  S.  Naval  Ordnance 
Laboratory  developed  a language  of  a completely  different  type.  This 
language  ADES  (Automatic  Digital  Encoding  System)  was  presented  at  the 
AIM  national  meetings  in  1955  [when  no  proceedings  were  published]  and 
1 O'  [BL  56"],  and  at  the  ONR  symposium  in  1956  [BL  56']. 

The  ADES  language  is  essentially  mathematical  in  structure.  It 
is  based  on  the  theory  of  the  recursive  functions  and  the  schemata 
for  such  functions,  as  given  by  Kleene.  [BL  56',  p.  72] 

The  ADES  approach  to  automatic  programming  is  believed  to  be 
entirely  new.  Mathematically,  it  has  its  foundations  in  the 
bedrock  of  the  theory  of  recursive  functions.  The  proposal 
to  apjly  this  theory  to  automatic  programming  was  first  made 
by  C.  C.  Elgot,  a former  colleague  of  the  author's.  While  at 
the  Naval  Ordnance  Laboratory,  Elgot  did  some  research  on  a 
language  for  automatic  programming.  Some  of  his  ideas  were 
adapted  to  ADES.  [BL  56,  p.  iii] 

A full  description  of  the  language  was  given  in  a lengthy  report 
[BL  56];  it  is  rather  difficult  to  understand  several  aspects  of  ADES, 
and  we  will  content  ourselves  with  a brief  glimpse  into  its  structure 
by  considering  the  following  ADES  program  for  TPK.  (The  conventions 
of  [BL  57']  are  followed  here  since  they  are  slightly  simpler  than  the 
original  proposals  in  [BL  56].) 


ao11:qo11' 

f50  = + / abs  C;L  • • • 5 cx  cx  cx, 
d12bl  = r0' 

d22b2  = - b3  4°0’  V 999, 

b3  = f50  ao  V 
ro  = ~10  V 

V 0 qQ  10  bQ  = fQ  t>1  ^2, 


Here  is  a rough  translation:  Line  1 is  the  so-called  "computer  table", 

meaning  that  input  array  aQ  has  11  positions,  and  the  "independent 
index  symbol"  takes  11  values.  Line  2 defines  the  auxiliary  function 

ft-Q  , our  f(t)  ; arithmetic  expressions  were  defined  in  Lukasiewicz's 
parentheses-free  notation,  now  commonly  known  as  "left  Polish".  Variable 
c^  here  denotes  the  first  parameter  of  the  function.  (incidentally, 

"right  Polish"  notation  seems  to  have  been  first  proposed  shortly 
afterwards  by  C.  L.  Hamblin  in  Australia,  cf.  [HA  57]*) 

Line  3 states  that  the  dependent  variable  b^  is  equal  to  the  dependent 
index  rQ  ; the  " d^  " here  means  that  this  is  to  be  output  as  component  1 
of  a pair.  Line  U similarly  defines  b0  , which  is  to  be  component  2 . 

This  line  is  a "branch  equation"  meaning  " if  b^  < LOO  then  b,.  ^else  999  "• 
(Such  branch  equations  are  an  embryonic  form  of  the  conditional  expressions 
introduced  later  by  McCarthy  into  LISP  and  ALGOL.  Blum  remarked  that  the 
equation  " < x a,  f,  g,  " could  be  replaced  by  cp  f + (l-cp)g  , where  cp 
is  a function  that  takes  the  value  1 or  0 according  as  x < a or 
x > a . [BL  56,  p.  16]  "The  function  cp  is  a primitive  recursive 
function,  and  could  be  incorporated  into  the  library  as  one  of  the  given 
functions  of  the  system.  Nevertheless,  the  branch  equation  is  included 
in  the  language  for  practical  reasons.  Many  mathematicians  are  accustomed 
to  that  terminology,  and  it  leads  to  more  efficient  programs."  In  spite 
of  these  statements,  Blum  may  well  have  intended  that  f or  g not  be 
evaluated  or  even  defined  when  cp  = 0 or  1 , respectively. ) 


! 

Line  5_  says  that  h is  the  result  of  applying  f^Q  to  the  -th 
element  of  aQ  . Line  6 explains  that  rQ  is  lO-q^  • Finally,  line  ~J_ 
is  a so-called  "phase  equation"  which  specifies  the  overall  program  flow 
by  saying  that  and  b^  are  to  be  evaluated  for  = 0,1,..., 10  . 

The  ADES  language  is  "declarative"  in  the  sense  that  Jne  programmer 
states  relationships  between  variable  quantities  without  explicitly 
specifying  the  order  of  evaluation.  John  McCarthy  put  it  this  way,  in  1958: 

Mathematical  notation  as  it  presently  exists  was  developed  to 
facilitate  stating  mathematical  facts,  i.e.,  making  declarative 
sentences.  A program  gives  a machine  orders  and  hence  is  usually 
constructed  out  of  imperative  sentences.  This  suggests  that  it 
will  be  necessary  to  invent  new  notations  for  describing  complicated 
procedures,  and  we  will  not  merely  be  able  to  take  over  intact  the 
notations  that  mathematicians  have  used  for  making  declarative 
sentences.  [EE  58',  p.  275] 

The  transcript  of  a 1965  discussion  of  declarative  vs.  inoperative  languages, 
with  comments  by  P.  Abrahams,  P.  Z.  Ingerman,  E.  T.  Irons,  P.  Naur, 

B.  Raphael,  R.  V.  Smith,  C.  Strachey,  and  J.  W.  Young,  appears  in 
Comm.  ACM  9 (1966),  pp.  155-156,  165-166. 

Although  ADES  was  based  on  recursive  function  theory,  it  did  not 
really  include  recursive  procedures  in  the  sense  of  ALGOL  60;  it  dealt 
primarily  with  special  types  of  recursive  equations  over  the  integers, 
and  the  emphasis  was  on  studying  the  memory  requirements  for  evaluating 
such  recurrences. 

An  experimental  version  of  ADES  was  implemented  on  the  IBM  650, 
and  described  in  [BL  57>  BL  57' ]•  Blum's  translator  scheme  was  vdiat 
we  now  recognize  as  a recursive  approach  to  the  problem,  but  the  recursion 
was  not  explicitly  stated;  he  essentially  moved  things  on  and  off  various 
.Jacks  during  the  course  of  the  algorithm.  This  implementation  points 
the  severe  problems  people  had  to  face  in  those  days:  The  ADES 

: - took  3500  instructions  while  the  Type  650  calculator  had  room 
for  r.I.y  2000,  so  it  was  necessary  to  insert  the  program  card  decks 

tchine  repeatedly,  once  for  each  equation!  Because  of  further 

tations,  the  above  program  would  have  been  entered  into  the 
unching  the  following  information  onto  six  cards: 
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A00 

Oil 

P02 

QPO 

Oil 

P01 

F50 

E00 

F02 

F20 

F06 

C01 

F0l+ 

FOk 

FOb 

005 

C01 

C01 

C01 

P01 

D12 

B01 

BOO 

R00 

F01 

D22 

B02 

E00 

Fll 

B03 

1+00 

F01 

B03 

P01 

999 

P01 

B03 

E00 

F50 

A00 

R00 

P01 

R00 

E00 

F03 

010 

QPO 

P01 

P03 

000 

QPO 

010 

BOO 

E00 

F00 

B01 

B02 

P01 

- 

- 

Thus  Pnn  was  a punctuation  mark,  Fnn  a function  code,  etc.  Actually 
the  implemented  version  of  ADES  was  a subset  that  did  not  allow 
auxiliary  f-equations  to  be  defined,  so  the  definition  of  b^  in 
line  5 would  have  been  written  out  explicitly. 


The  IT. 

In  September,  1955>  four  members  of  the  Purdue  University 
Computing  Laboratory  — Mark  Koschman,  Sylvia  Orgel,  Alan 
Perlis,  and  Joseph  W.  Smith  --  began  a series  of  conferences 
to  discuss  methods  of  automatic  coding.  Joanne  Chipps  joined 
the  group  in  March,  1956.  A compiler,  programmed  to  be  used 
on  the  Datatron,  was  the  goal  and  result.  [OR  58,  p.  1] 

Purdue  received  one  of  the  first  Datatron  computers,  manufactured  by 
Electrodata  Corporation  (cf.  J.  ACM  2 (1955 )>  p.  122,  and  [PE  55]);  this  machine 
was  later  known  as  the  Burroughs  205 • By  the  summer  of  1956,  the  Purdue 
group  had  completed  an  outline  of  the  basic  logic  and  language  of  its 
compiler,  and  they  presented  some  of  their  ideas  at  the  ACM  national 
meeting  [CK  56].  It  is  interesting  to  note  that  their  1956  paper 
used  both  the  words  "compiler"  and  "statement"  in  the  modem  sense; 
a comparison  of  the  ONR  195*+  and  1956  symposium  proceedings  makes  it 
clear  that  the  word  "compiler"  had  by  now  acquired  its  new  meaning. 

Furthermore  the  contemporary  FORTRAN  manuals  [IB  56,  IB  57]  also  used 
the  term  "statement"  where  [IB  5*+]  had  said  "formula".  Terminology  was 
crystallizing. 

At  this  time  Perlis  and  Smith  moved  to  the  Carnegie  Institute  of 
Technology,  taking  copies  of  tb  flowcharts  with  them,  and  they  adapted 
their  language  to  the  IBM  650  (a  smaller  machine)  with  the  help  of 
Harold  Van  Zoeren.  The  compiler  was  put  into  use  in  October,  1956, 

(cf.  [PS  57>  P*  102]),  and  it  became  known  as  IT,  the  Internal  Translator. 


» 
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Compilation  proceeds  in  two  phases:  l)  translation  from  an  IT 

program  into  a symbolic  program,  PIT  and  2)  assembly  from  a PIT 
program  into  a specific  machine  coded  program,  SPIT.  [PS  57 ' > P*  1»2J] 

The  intermediate  "PIT"  program  was  actually  a program  in  SOAP  language  [PM  55 ]> 
the  source  code  for  an  excellent  symbolic  assembly  program  for  the  IBM  650. 
Perlis  has  stated  that  the  existence  of  SOAP  was  an  important  simplifying 
factor  in  their  implementation  of  IT,  which  was  completed  about  three 
months  after  its  authors  had  learned  the  650  machine  language. 

This  was  the  first  really  useful  compiler;  IT  and  IT's  derivatives  were 
used  successfully  and  frequently  in  hundreds  of  computer  installations  until 
the  650  became  obsolete.  (indeed,  R.  B.  Wise  stated  in  October,  1958 
that  "the  IT  language  is  about  the  closest  thing  we  have  today  to  the  universal 
language  among  computers."  [WA  58,  p.  131] ) The  previous  systems  we  have 
discussed  were  important  steps  along  the  way,  but  none  of  them  had  the 
combination  of  powerful  language  and  adequate  implementation  and  documentation 
needed  to  make  a significant  impact  in  the  use  of  machines.  Furthermore,  IT 
proved  that  useful  compilers  could  be  constructed  for  small  computers 
without  enormous  investments  of  manpower. 

Here  is  an  IT  program  for  TPK: 

1:  READ 

2:  3,11,10,-1,0, 

5:  Y1  - ”20E,AC(I1+1)" 

+ (5x(c(n+l)*3)) 

6:  G3  IF  400.0  > Y1 

7 : Y1  *-  999 

3 : Til  TY1 

10:  H 

Each  statement  has  an  identifying  number,  but  the  numbers  do  not  have  to 
be  in  order.  The  READ  statement  does  not  specify  the  names  of  variables 
being  input,  since  such  information  appears  on  the  data  cards  themselves. 
Floating-point  variables  are  called  Yl,  Y2,  ...  or  Cl,  C2, . . . ; the  above 
program  assumes  that  the  input  data  will  specify  eleven  values  for  Cl 
thru  Cll. 

Statement  number  2 designates  an  iteration  of  the  following  program  through 
statement  number  3 inclusive;  variable  II  runs  from  10  in  steps  of  -1 
down  to  0.  Statement  5 sets  Yl  to  f(Cj]_+i)  > the  notation  " 20E, x " 
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is  used  for  "language  extension  20  applied  to  x",  where  extension  20 
happens  to  be  the  floating-point  square  root  subroutine.  Note  the  use 
of  mixed  integer  and  floating-point  arithmetic  here.  The  redundant 
parentheses  emphasize  that  IT  did  not  deal  with  operator  precedence, 
although  in  this  case  the  parentheses  need  not  have  been  written  since 
IT  evaluated  expressions  from  right  to  left. 

The  letter  A is  used  to  denote  absolute  value,  and  * means 
exponentiation.  Statement  6 goes  to  3 if  Y1  < 400  ; and  statement  3 
outputs  II  and  Y1  . Statement  10  means  "halt". 

Since  the  IBM  650  did  not  have  such  a rich  character  set  at  the 
time,  the  above  program  would  actually  be  punched  onto  cards  in  the 
following  form  --  using  K for  comma,  M for  minus,  Q for  quote, 

L and  R for  parentheses,  etc.: 


0001 

READ 

F 

0002 

3K  I1K  10K  MLK  OK 

F 

0005 

Y1  Z Q 20 EK  ACLI1S1R 

Q F 

0005 

S L5  X LCLI1S1R 

P 3RR  F 

0006 

G3  IF  hOOJO  W Y1 

F 

0006 

Yl  z 999 

F 

0003 

Til  TYl 

F 

0010 

H 

FF 

The  programmer  also  supplied  a "header  card",  stating  the  limits  on 

array  subscripts  actually  used;  in  this  case  the  header  card  would 

say  1 I variable,  1 Y variable,  11  C variables,  10  statements. 

(it  was  possible  to  "go  to"  statement  number  n,  where  n was  the  value 
of  any  integer  expression,  so  an  array  of  statement  locations  was  kept 
in  the  running  program.) 

The  Purdue  compiler  language  discussed  in  [CK  56'}  was  in  some  respects 
richer  than  this,  it  included  the  ability  to  type  out  alphabetic  information 
and  to  define  new  extensions  (functions)  in  source  language.  On  the  other 
hand,  [CK  56]  did  not  mention  iteration  statements  or  data  input.  Joanne 
Chipps  and  Sylvia  Orgel  completed  the  D at at r on  implementation  in  the 
summer  of  1957 > the  language  had  lost  the  richer  features  in  [CK  56],  however, 
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probably  since  they  were  unexpectedly  difficult  to  implement.  Our 
program  in  the  Purdue  Compiler  language  [OR  58]  would  look  like  this: 


[maximum  subscripts  used] 

[read  input] 

[set  iQ  = 10] 

[go  to  8 if  y^  < 400.0] 

[output  i^] 

[output  y ] 

[go  to  5 if  iQ  > 0] 

[ halt ] 

■ 

Note  that  subscripts  now  may  start  with  0 , and  that  each  statement 
begins  with  a letter  identifying  its  type.  There  are  enough  differences 
between  this  language  and  IT  to  make  mechanical  translation  nontrivial. 

FORTRAN  Arrives. 

During  all  this  time  the  ongoing  work  on  FORTRAN  was  widely  publicized. 

Max  Goldstein  may  have  summed  up  the  feelings  of  many  people  when  he  made 
the  following  remark  in  June,  1956:  "As  far  as  automatic  programming 

goes,  we  have  given  it  some  thought  and  in  the  scientific  spirit  we 
intend  to  try  out  FORTRAN  when  it  is  available.  However  ..."  [GO  56,  p.  40] 

The  day  was  coming.  October,  1956,  witnessed  another  "first"  in 
the  history  of  programming  languages,  namely  a language  description  which 
was  carefully  written  and  beautifully  typeset,  neatly  bound  with  a glossy 
cover.  It  began  thus: 

This  manual  supersedes  all  earlier  information  about  the  Fortran 
system.  It  describes  the  system  which  will  be  made  available  during 
late  1956,  and  is  intended  to  permit  planning  and  Fortran  coding  in 
advance  of  that  time.  [IB  56,  p.  1] 

Object  programs  produced  by  Fortran  will  be  nearly  as  efficient 
as  those  written  by  good  programmers,  [p.  2] 


input  iO  yO  clO  slO  f 

1 e "8O0e"  f 

2 s iO  = 10  f 

5 s yO  = "200e,  aciO"+(5x(ciOp3) ) f 

6 r g8,  r yO  < 1+00.0  f 

7 s yO  = 999  f 

8 o iO  f 

9 o yO  f 

U s iO  = iO-1  f 

3 r g5,  r 0 < iO  f 

10  h f 
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"Late  1956"  was,  of  course,  a euphemism  for  April,  1957-  Here  is  how 
Saul  Rosen  described  FORTRAN'S  debut: 


! 
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Like  most  of  the  early  hardware  and  software  systems,  Fortran 
was  late  in  delivery,  and  didn't  really  work  when  it  was 
delivered.  At  first  people  thought  it  would  never  be  done. 

Then  when  it  was  in  field  test,  with  many  bugs,  and  with  some 
of  the  most  important  parts  unfinished,  many  thought  it  would 
never  work.  It  gradually  got  to  the  point  where  a program 
in  Fortran  had  a reasonable  expectancy  of  compiling  all  the 
way  through  and  maybe  even  of  running.  [RO  64] 

In  spite  of  these  difficulties,  it  is  clear  that  FORTRAN  I was 
worth  waiting  for;  it  soon  was  accepted  even  more  enthusiastically 
than  its  proponents  had  dreamed. 

A survey  in  April  of  this  year  [1958]  of  twenty-six  704  installations 
indicates  that  over  half  of  them  use  FORTRAN  for  more  than  half 
of  their  problems.  Many  use  it  for  80$  or  more  of  their  work 
(particularly  the  newer  installations)  and  almost  ail  use  it 
for  some  of  their  work.  The  latest  records  of  the  704  users' 
organization,  SHARE,  show  that  there  are  some  sixty  installations 
equipped  to  use  FORTRAN  (representing  66  machines)  and  recent 
reports  of  usage  indicate  that  more  than  half  the  machine 
instructions  for  these  machines  are  being  produced  by  FORTRAN. 

[BA  58,  p.  246] 

On  the  other  hand,  not  everyone  had  been  converted.  The  second 
edition  of  programming's  first  textbook,  by  Wilkes,  Wheeler,  and  Gill, 
was  published  in  1957?  and  'the  authors  concluded  their  newly- added 
chapter  on  "automatic  programming"  with  the  following  cautionary 
remarks : 
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The  machine  might  accept  formulas  written  in  ordinary- 
mathematical  notation,  and  punched  on  a specially  designed 
keyboard  perforator.  This  would  appear  at  first  sight  to 
be  a very  significant  development,  promising  to  reduce 
greatly  the  labor  of  programming.  A number  of  schemes  of 
formula  recognition  have  been  described  or  proposed,  but 
on  examination  they  are  found  to  be  of  more  limited  utility 
than  might  have  been  hoped.  . . . The  best  that  one  could 
expect  a general  purpose  formula-recognition  routine  to  do, 
would  be  to  accept  a statement  of  the  problem  after  it  had 
been  examined,  and  if  necessary  transformed,  by  a numerical 
analyst.  ...  Even  in  more  favorable  cases,  experienced 
programmers  will  be  able  to  obtain  greater  efficiency  by 
using  more  conventional  methods  of  programming.  [WW  57>  pp.  I56-I37] 

An  excellent  paper  by  the  authors  of  FORTRAN  I,  describing  both  the  language 
and  the  organization  of  the  compiler,  was  presented  at  the  Western  Joint  Computer 
Conference  in  1957  [BB  57 1 * The  new  techniques  for  global  program  flow  analysis 
and  optimization,  due  to  Robert  A.  Nelson,  Irving  Ziller,  Lois  M.  Baibt,  and 
Sheldon  Best,  were  particularly  important.  By  expressing  TPK  in  FORTRAN  I 
we  can  see  most  of  the  language  changes  that  had  occurred: 


C 


1 


k 

5 

8 

9 

10 


THE  TPK  ALGORITHM,  FORTRAN  STYLE 
FUNF(T)  = SQRTF(ABSF(T))+5-0*T**3 
DIMENSION  A(ll) 

FORMAT (6F12.U) 

READ  1,  A 
DO  10  J = 1, 11 
I = 11-J 

Y = FUNF(A(l+l) ) 

IF  (kOO.O-Y)b,8,8 
PRINT  5,  I 

FORMAT (110,  10H  TOO  LARGE) 

GO  TO  10 
PRINT'  9,  I,  Y 
FORMAT (110,  F12.7) 

CONTINUE 
STOP  52525 
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The  chief  innovations  are 

(1)  Provision  for  comments:  No  programming  language  designer  had  thought 

to  do  this  before'.  (Assembly  languages  had  comment  cards,  but 
programs  in  higher-level  languages  were  generally  felt  to  be  self- 
explanatory  . ) 

(2)  Arithmetic  statement  functions  were  introduced.  These  were  not 
mentioned  in  [IB  56],  but  they  appeared  in  [BB  57]  and  (in  detail) 
in  the  Programmer's  Primer  [IB  57>  pp.  25,  30-31] • 

(3)  Formats  are  provided  for  input  and  output.  This  feature,  due  to 
Roy  Nutt,  was  a major  innovation  in  programming  languages;  it 
probably  had  a significant  effect  in  making  FORTRAN  popular  since 
input/output  conversions  were  otherwise  very  awkward  to  express 
on  the  70t. 

(k)  Lesser  features  not  present  in  [IB  5k]  are  the  CONTINUE  statement, 
and  the  ability  to  display  a five-digit  octal  number  when  the 
machine  halted  at  a STOP  statement. 

MATO-j^IC_  jUTd  FLW-MATIC. 

Meanwhile,  Grace  Hopper's  programming  group  at  UNIVAC  had  also  been  busy. 
They  had  begun  to  develop  an  algebraic  language  in  1955*  a project  that  was 
headed  by  Charles  Katz,  and  the  compiler  was  released  to  two  installations  for 
experimental  tests  in  1956.  (Cf.  [BE  57],  p.  112.)  The  language  was  originally 
called  AT-3 ; but  it  received  the  catchier  name  MATH-MATIC  in  April,  1957>  when 
its  preliminary  manual  [AB  57]  was  released.  The  following  program  for  TPK 
gives  MATH-MATIC 's  flavor: 

(l)  READ- ITEM  A(ll)  . 

(2)  VARY  I 10(-1)0  SENTENCE  3 THRU  10  . 

(3)  J = 1+1  . 

(k)  Y = SQR  | A(J) | + 5*A(J)3  . 

(5)  IF  Y > Uoo,  JUMP  TO  SENTENCE  8 . 

(6)  PRINT-OUT  I,  Y . 

(7)  JUMP  TO  SENTENCE  10  . 

(8)  Z = 999  • 

(9)  PRINT-OUT  I,  Z . 

(10)  IGNORE  . 

(11)  STOP  . 
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The  language  was  quite  readable;  note  the  vertical  bar  and  the  superscript 
3 in  sentence  (k),  indicating  an  extended  character  set  that  could  be 
used  with  some  peripherals.  But  the  MATH-MATIC  programmers  did  not  share 
the  FORTRAN  group’s  enthusiasm  for  efficient  machine  code;  they  translated 
MATH-MATIC  source  language  into  A-3  (an  extension  of  A-2),  and  this 
produced  extremely  inefficient  programs,  especially  considering  the  fact 
that  arithmetic  was  all  done  by  floating-point  subroutines.  The  UNIVAC 
computer  was  no  match  for  an  IBM  70k  even  when  it  was  expertly  programmed, 
so  MATH-MATIC  was  of  limited  utility. 

The  other  product  of  Grace  Hopper's  programming  staff  was  far  more 
influential  and  successful,  since  it  broke  important  new  ground.  This 
was  what  she  originally  called  the  Data- Processing  compiler  in  January, 

1955;  it  was  soon  to  be  known  as  "B-0",  later  as  the  "Procedure 
Translator"  [KM  57 L and-  finally  as  FLOW-MATIC  [HO  58,  TA  60] . This 
language  used  English  words,  somewhat  as  MATH-MATIC  did  but  more  so, 
and  its  operations  concentrated  on  business  applications.  The  following 
examples  are  typical  of  FLOW-MATIC  operations: 

(1)  COMPARE  PART-NUMBER  (a)  TO  PART-NUMBER  (B)  ; IF  GREATER  GO  TO 
OPERATION  13  ; IF  EQUAL  GO  TO  OPERATION  k ; OTHERWISE  GO  TO 
OPERATION  2 . 

(2)  READ- ITEM  B ; IF  END  OF  DATA  GO  TO  OPERATION  10  . 

The  allowable  English  templates  are  shown  in  [SA  69,  pp.  317-522]. 

The  first  experimental  B-0  compiler  was  operating  in  1956  [HO  58, 
p.  171],  and  it  was  released  to  UNIVAC  customers  in  1958  [SA  69,  p.  316] • 
FLOW-MATIC  had  a significant  effect  on  the  design  of  COBOL  in  1959* 

AJomula^-c ontr oiled  Computer. 

At  the  international  computing  colloquium  in  Dresden,  1955;  Klaus  Bamelson 
presented  the  rudiments  of  a particularly  elegant  approach  to  algebraic 
formula  recognition  [SA  55]>  improving  on  Bohm's  technique.  Samelson  and 
his  colleague  F.  L.  Bauer  developed  this  method  during  the  ensuing  years, 
and  their  subsequent  paper  [SB  59]  describing  it  became  well  known. 
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One  of  the  first  things  they  did.  with  their  approach  was  to  design 
a computer  in  which  algebraic  formulas  themselves  were  the  machine 
language.  This  computer  design  was  submitted  to  the  German  patent  office 
in  the  spring  of  1957  [BS  57 L and  to  the  U. S.  patent  office  (with  the 
addition  of  wiring  diagrams)  a year  later.  Although  the  German  patent  was 
never  granted,  and  the  machines  were  never  actually  constructed,  Bauer  and 
Samelson  eventually  received  U.S.  Patent  3>0k7,228  for  this  work  [BS  62]. 

Their  patent  describes  four  possible  levels  of  language  and  machine.  At 
the  lowest  level  they  introduced  something  like  the  language  used  on  today’s  pocket 
calculators,  allowing  formulas  consisting  only  of  operators,  parentheses, 
and  numbers,  while  their  highest  level  includes  provision  for  a full- 
fledged  programming  language  incorporating  such  features  as  variables 
with  multiple  subscripts  and  decimal  arithmetic  with  arbitrary  precision. 

The  language  of  Bauer  and  Samelson' s highest-level  machine  is  of 
principal  concern  to  us  here.  A program  for  TPK  could  be  entered  on 
its  keyboard  by  typing  the  following: 


1 O 0000. 00000000  =*  alllT 

2 2.27  =>  ailt 

3 3.328  =>  al2t 

• • • 

12  5.28761  =>  a HIT 


lk  Ik*  aii+lt  =>  t 

15  / Bt+5xtxtxt  =>  y 

16  i = □ □ =*  i 

1£  y > kOO  - 77* 

18  y = □ □ U .□  □ U =>  y 

19  88* 

20  77*  999  -□□□.□□□=*  y 

21  88*  i-l  =»  i 

22  i > -1  ->  kk* 


(This  is  the  Amerie  n version;  the  German  version  would  be  the  same  if 
all  the  decimal  points  were  replaced  by  commas. ) 
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The  " ^ " at  the  beginning  of  this  program  is  optional;  it  means  that 
the  ensuing  statements  up  to  the  next  label  ( 1+4*  ) will  not  enter  the 
machine's  "formula  storage",  they  will  simply  be  performed  and  forgotten. 

The  remainder  of  line  1 specifies  storage  allocation;  it  says  that  a is 
an  11-element  array  whose  entries  will  contain  at  most  12  digits. 

Lines  2 through  12  enter  the  data  into  array  a . The  machine  also 
included  a paper  tape  reader  in  addition  to  its  keyboard  input;  and  if  the 
data  were  to  be  entered  from  paper  tape,  lines  2 through  12  could  be 
replaced  by  the  code 

1 =>  i 

33*  ••••••  =>  aiit 

l+1  =>  i 
i < 12  - 33* 

Actually  this  input  convention  was  not  specifically  mentioned  in  the  patent, 
but  Bauer  [BA  y6 * ] recalls  that  such  a format  was  intended. 

The  symbols  J and  t for  subscripts  would  be  entered  on  the  keyboard 
but  they  would  not  actually  appear  on  the  printed  page;  instead,  the 
printing  mechanism  was  intended  to  shift  up  and  down.  The  equal  signs 
followed  by  square  boxes  on  lines  16,  18,  and  20  indicate  output  of  a 
specified  number  of  digits,  showing  the  desired  decimal  point  location. 

The  rest  of  the  above  program  should  be  self-explanatory,  except  perhaps 
for  the  B in  line  15  which  denotes  absolute  value  ("Betrag" ) . 

Summary . 

We  have  now  reached  the  end  of  our  story,  having  covered  essentially 
every  high-level  language  whose  design  began  before  1957*  It  is 
impossible  to  summarize  all  of  the  languages  we  have  discussed  by 
preparing  a neat  little  chart;  but  everybody  likes  to  see  a neat  little 
chart,  so  here  is  an  attempt  at  a rough  but  perhaps  meaningful  comparison. 
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Table  1 shows  the  principal  mathematic ally -oriented  languages  we 
have  discussed,  together  with  their  chief  authors  and  approximate  year 
of  greatest  research  or  development  activity.  The  "arithmetic"  column 
shows  X for  languages  that  deal  with  integers,  F for  languages  that 
deal  with  floating-point  numbers,  and  S for  languages  that  deal  with 
scaled  numbers.  The  remaining  columns  of  Table  1 are  filled  with  very 
subjective  "ratings"  of  the  languages  and  associated  programming  systems 
according  to  various  criteria. 

Implementation:  Was  the  language  implemented  on  a real  computer? 

If  so,  how  efficient  and/or  easy  to  use  was  it? 

Readability:  How  easy  is  it  to  read  programs  in  the  language? 

(This  includes  such  things  as  the  variety  of  symbols  usable 
for  variables,  the  closeness  to  familiar  notations.) 

Control  structures:  How  high-level  are  the  control  structures? 

Are  the  existing  control  structures  sufficiently  powerful? 

(By  "high  level"  we  mean  a level  of  abstraction;  something 
the  language  has  that  the  machine  does  not.) 

Data  structures:  How  high-level  are  the  data  structures?  (For 

example,  can  variables  be  subscripted?) 

Machine  independence:  How  much  does  a programmer  need  to  keep 

in  mind  about  the  underlying  machine? 

Impact:  How  many  people  are  known  to  have  been  directly  influenced 

by  this  work  at  the  time? 

Finally  tnere  is  a column  of  "firsts",  which  states  some  new  thing(s) 
this  particular  language  or  system  introduced. 

The  Sequel. 

What  have  we  not  seen,  among  all  these  languages?  The  most  significant 
gaps  are  the  lack  of  high-level  data  structures  other  than  arrays  (except 
in  Zuse's  unpublished  language);  the  lack  of  high  level  control  structures 
other  than  iteration  controlled  by  an  index  variable;  and  the  lack  of 
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recursion.  These  three  concepts,  which  now  are  considered  absolutely 
fundamental  in  computer  science,  did  not  find  their  way  into  languages 
until  the  1960's.  Our  languages  today  probably  have  too  many  features, 
but  the  languages  up  to  FORTRAN  I had  too  few. 

At  the  time  our  story  leaves  off,  explosive  growth  in  language 
development  was  about  to  take  place,  since  the  successful  compilers 
touched  off  a language  boom.  Programming  languages  had  reached  a stage 
when  people  began  to  write  translators  from  IT  to  FORTRAN  [GR  58]  and 
from  FORTRAN  to  IT  (cf.  [BO  58],  who  describes  the  FOR  TRANSIT  compiler 
which  was  developed  by  a group  of  programmers  at  IBM  under  the  direction 
of  R.  W.  Bemer  and  D.  Hemmes).  An  excellent  survey  of  the  state  of 
automatic  programming  at  the  time  was  prepared  by  R.  W.  Bemer  [BE  57 3 • 

Perhaps  the  most  significant  development  then  in  the  wind  was  the 
international  project  attempting  to  define  a "standard"  algorithmic 
language.  Just  after  the  1955  meeting  in  Darmstadt,  a group  of 
European  computer  scientists  began  to  plan  a new  language  (cf.  [LE  55]), 
under  the  auspices  of  the  Gesellschaft  fur  Angewandte  Mathematik  und 
Mechanik  (GAMM,  the  Association  for  Applied  Mathematics  and  Mechanics). 
They  later  invited  American  participation,  and  an  ad  hoc  ACM  committee 
chaired  by  Alan  Perils  met  several  times  beginning  in  January,  1958. 
During  the  siammer  of  that  year,  Zurich  was  the  site  of  a meeting  attended 
by  representatives  of  the  American  and  European  committees:  J.  W.  Backus, 

F.  L.  Bauer,  H.  Bottenbruch,  C.  Katz,  A.  J.  Perlis,  H.  Rutishauser, 

K.  Samelson,  and  J.  H.  Wegstein.  (Gee  [BB  58]  for  the  language  proposed 
by  the  European  delegates.) 

It  seems  fitting  to  bring  our  story  to  a close  by  stating  the  TPK 
algorithm  in  the  "International  Algebraic  Language"  (IAL,  later  called 
ALGOL)  developed  at  that  historic  Zurich  meeting  [FS  58] : 
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procedure  TPK  (a[ ] ) =:  b[]; 
array  (a[0:10],b[0:21] ) ; 

comment  given  11  input  values  a[0],  . . a[10],  this  procedure 
produces  22  output  values  b[0],  . . .,b[2l],  according 
to  the  classical  TPK  algorithm; 
begin  £or  i :=  10(-1)0; 
begin  y :=  f (a[i] ) ; 

f(t)  :=  sqrt(abs(t) ) + 5 x tt3  i; 
if  (y  > 400);  y :=  999; 
b[20-2xi]  :=  i; 
b [21-2xi]  :=  y 

end; 
return ; 
integer  (i) 
end  TPK 
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[AB  57l 
[AL  5l] 


[BA  5b] 
[BA  58] 

[BA  59] 

[BA  61] 
[BA  76] 

[BA  76' ] 
[BB  57] 
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